Re: NSLock locking order;
Re: NSLock locking order;
- Subject: Re: NSLock locking order;
- From: Shawn Erickson <email@hidden>
- Date: Thu, 10 Nov 2005 11:10:31 -0800
On Nov 10, 2005, at 10:37 AM, Matt Budd (Madentec) wrote:
Hello all,
Say I have three threads competing for the same NSLock. Here's some
small psuedo code:
Thread A, B, and C (just with different "<stuff>")
--------------------------------------------------------------
while (YES) {
[_oLock lock];
<stuff>
[_oLock unlock];
[NSThread sleepUntilDate: [NSDate dateWithTimeIntervalSinceNow:
0.5]];
}
So lets say thread A got the the lock first, and then then got
swapped out while doing "<stuff>". Then thread B blocks attempting
to acquire the lock. Then thread C runs and also blocks attempting
to acquire the lock. Then we get back to thread A and it finishes
its "<stuff>", unlocks the _oLock, and sleeps for half a second.
Is there any order to who will get to acquire the lock next?
No, at least not one that you can depend on (you would be depending
on an implementation detail of the scheduler and NSLock). If you need
a predictable order you would have to implement a FIFO locking
construct of some type (google for examples).
Does thread B get it because it is queued up somewhere in the
foundation's NSLock class that it is first?
It may or it may not. Nothing in NSLock's implementation implies a
particular order.
Or is there a possibility that thread A might finish its sleep and
loop around and obtain the lock again?
Possibly but not likely if both B and C are already blocked waiting
on the lock, half a second is a very long time for the other thread
to get marked runnable and scheduled.
Or does thread C have a chance?
In general the schedular in Mac OS X is fair so the blocked threads
should get a chance to run and acquire the lock. In other words in
your example you don't need the to sleep any thread unless your
really want to explicitly give a window of time for others to get a
crack at the lock without competition from the sleeping thread.
Hard to fully answer what is or is not needed knowing little about
your end goal (for example consumer / producer threading constructs
use the availability of "product" to throttle thread activity).
Review...
<http://developer.apple.com/technotes/tn/tn2028.html#MacOSXThreading>
-Shawn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden