Re: NSConditionLock console message: "unlocked from thread which did not lock it"
Re: NSConditionLock console message: "unlocked from thread which did not lock it"
- Subject: Re: NSConditionLock console message: "unlocked from thread which did not lock it"
- From: Chris Kane <email@hidden>
- Date: Tue, 27 Nov 2007 13:32:35 -0800
On Nov 25, 2007, at 9:40 AM, Mark Alldritt wrote:
Under Leopard, my application has begun logging console messages
like this:
2007-11-25 09:09:03.572 Script Debugger 4[66788:613] *** -
[NSConditionLock
unlockWithCondition:]: lock (<NSConditionLock: 0x2b5e7ed0> '(null)')
unlocked from thread which did not lock it
The message is correct: I lock the NSConditionLock from a worker
thread to
block the thread until another thread (the main thread) receives a
response
and the worker can continue on.
This seems to me like a legitimate use of a lock. Can anyone
explain what
the problem here is.
POSIX does not require unlocking from a different thread to work
properly, though it may, so as NSLock and related are built on top of
the pthreads API, the same is true there as well.
What you want to do is lock and unlock in the same thread, in both
threads. NSConditionLock, which you're already using, makes this
straightforward, whereas it is not possible with plain NSLocks. For
example, to block the background thread:
[condLock lockWhenCondition:1]; // block until 1
[condLock unlock];
In the main thread:
[condLock lock];
[condLock unlockWithCondition:1]; // 1 means background thread can
proceed
assuming that the lock was created/initialized with -initWithCondition:
0.
Chris Kane
Cocoa Frameworks, Apple
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden