Re: NSConditionLock console message: "unlocked from thread which did not lock it"

FROM : Scott Ribe
DATE : Sun Nov 25 19:26:51 2007

> This seems to me like a legitimate use of a lock.  Can anyone explain what
> the problem here is.


>From the docs on NSLock:


> Warning: The NSLock class uses POSIX threads to implement its locking
> behavior. When sending an unlock message to an NSLock object, you must be sure
> that message is sent from the same thread that sent the initial lock message.
> Unlocking a lock from a different thread can result in undefined behavior.


NSCondition probably uses NSLock in its implementation. You might want to
file a bug against the docs, that the warning should be repeated or
referenced in the NSCondition docs.

Most of the time, code that takes any kind of lock in one thread and
releases it in another is wrong. Such code usually has race conditions,
because such code usually at some point has an inter-thread sequence that
behaves similarly to the naïve "if !myflag then" vs "myflag = true" type of
resource protection.

You may have the exception, where external factors guarantee that your main
thread never receives a response and unlocks just before a worker thread
locks, and that the worker thread always completes taking the lock before
the main thread releases it. But are you sure? Are you 100% sure that the
following sequence could never occur?

1) worker posts request to main thread
2) main thread processes request
3) main thread receives response
4) main thread signals
5) worker thread waits for signal, and waits, and waits...


--
Scott Ribe
<email_removed>
http://www.killerbytes.com/
(303) 722-0567 voice