The thing to remember about NSConditionLock is that it's a lock that can only
be acquired when it's in the specified condition.
So for example, the lock can start in condition 0. Thread B can lock when in
condition 0 while thread A can simultaneously lock when the condition is 1.
This means thread B acquires the lock, and thread A blocks on a change in the
lock's condition. Thread B then unlocks with condition 1, so thread A can then
acquire the lock.
- (void)threadA:(id)object
{
// a lock for coordination between multiple threads
NSConditionLock *lock = [[NSConditionLock alloc] initWithCondition:0];
// start thread B
[NSThread detachNewThreadSelector:@selector(threadB:) toTarget:self
withObject:lock];
// wait for thread B to do something
[lock lockWhenCondition:1];
// be sure lock is unlocked before releasing it (on thread which
created it)
[lock unlockWithCondition:0];
[lock release];
// do whatever
}
- (void)threadB:(id)object
{
NSConditionLock *lock = object;
[lock retain];
// acquire lock immediately
[lock lockWhenCondition:0];
// do whatever thread A needs to wait for
// unlock in a state that allows thread A to run
[lock unlockWithCondition:1];
[lock release];
}
Hope this helps!
-- Chris
On May 5, 2011, at 12:08 PM, eveningnick eveningnick wrote:
> Ken,
> Thanks for a detailed response
> Still not sure how would it be possible to do using NSConditionLock,
> but i managed to do it using NSCondition :)
>
>
> 2011/5/5 Ken Thomases <k...@codeweavers.com>:
>> On May 5, 2011, at 8:51 AM, eveningnick eveningnick wrote:
>>
>>> 2011/5/5 Heath Borders <heath.bord...@gmail.com>:
>>>> Try NSConditionLock. Its documentation should be pretty self-explanatory.
>>>>
>>>
>>> Health,
>>> thanks for the response.
>>> However, i can't see how can i use NSConditionLock in my situation.
>>> For every lock (or mutex/semaphore - which essentially is the same) i
>>> need to acquire it 1 time at least to stop the the thread when a
>>> second attempt to acquire it from a different thread is made.
>>> What i need - is to stop the thread A immediately after the thread B
>>> has been spawned by a thread A. I am afraid if i acquire the lock from
>>> A, and then acquire it as soon as B starts (in B routine), the thread
>>> A may even finish before the thread B _actually_ starts (or rather B's
>>> threadfunction starts executing).
>>> Am i wrong somewhere here?
>>
>> NSConditionLock allows one to lock waiting for specific conditions. The
>> lock can be created in an initial condition, say THREAD_B_NOT_RUNNING.
>> Then, Thread A can spawn B and lock waiting for condition THREAD_B_RUNNING.
>> Thread B can take the lock unconditionally and, when it's ready, unlock it
>> with condition THREAD_B_RUNNING. Or whatever.
>>
>> Other possible techniques include using a pipe to send a signal byte from
>> one thread to the other. So, thread A would do a blocking read from the
>> pipe. Thread B would write a single byte to the pipe to signal whatever
>> condition.
>>
>> There are all sorts of other approaches.
>>
>> Regards,
>> Ken
>>
>>
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/cmh%40me.com
>
> This email sent to c...@me.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
