Re: An actual NSLock bug

[Alexander Malmberg]

Morgan Giddings wrote:
> Thanks Alex and Adam for the discussion/suggestions.
> 
> While I had considered using NSCondition locks, it is not yet clear 
> to me how I could extend this to launch an arbitrary number of 
> simultaneous processes.  In the code I showed you there was the 
> simplifying assumption that only one child thread would run at a 
> time.

Well, the code I gave was equivalent to the code you'd get with the lock
semantics you expect (as I understand them, and modulo any mistakes, of
course ;), so extending it to multiple threads wouldn't be any problem
(with one lock per thread or whatever).

To explain a bit more, the "lock" of NS*Lock is just there to protect
something from being accessed from more than one thread, so it shouldn't
be manipulated from more than one thread at a time. If you want a lock
that you can lock and unlock from different threads, you need to think
of the state of that lock as the _condition_ of the NSConditionLock, not
the actual lock state of NSConditionLock. Thus, replacing 1 and 0 with
named constants, we get:

>> [lock lockWhenCondition: UNLOCKED];
>> [lock unlockWithCondition: LOCKED];

I.e. blocks until the "lock" (really the condition) is in the unlocked
state, and
when it is, move it to the locked state. And:

>> [lock lockWhenCondition: LOCKED];
>> [lock unlockWithCondition: UNLOCKED];

Blocks until the lock is in the locked state*, and when it is, move it
to the unlocked state.

(*A bit odd behavior, but unlocking a lock that isn't locked is an
odd case; if you want different behavior here, you can use e.g.
-lock and -condition directly.)

The lock of NSConditionLock just ensures that only one thread at a time
can touch the condition.

Adam Fedor wrote:
> Well, sure, I don't think we should forbid a developer from doing 
> something crazy if they really want to. Particularly in this case 
> since there is no work-around when the exception is called. Perhaps 
> changing the exception to a warning (GSOnceMLog). Any opinions?

Well, as far as I can tell, the exception is there to catch misuses
caused by the slightly unusual behavior of the NS*Lock classes, and
that's what it has done.

- Alexander Malmberg