Re: question: NSThread & NSLock
Re: question: NSThread & NSLock
- Subject: Re: question: NSThread & NSLock
- From: Chris Suter <email@hidden>
- Date: Mon, 29 May 2006 21:40:09 +1000
On 29/05/2006, at 9:17 PM, Karim Morsy wrote:
Hi,
I have multiple threads trying to access one critical section.
I protect that region with an NSLock. now, what I'm not sure about
is...
when one thread holds the lock and let's say three other threads
try to acquire it while the first thread is still
inside the critical section, which of the waiting threads will get
access once the first thread unlocks ?
are the threads waiting in a queue, is one thread chosen randomly
or by priority ?
I believe that NSLock uses pthread_mutex under the covers so it will
be the same behaviour as that. However, you shouldn't rely on any
behaviour with regards to which thread is chosen; you should write
your code assuming the threads could be chosen at random.
what I'm doing is the following:
one thread is loading audio data (it acquires an nslock for the
critical section where loading and initialization is done). if a
user choses a different audio file, while one thread is still
loading it should stop, clean up and release the lock (I have a
global BOOL "shouldStopInit" variable which the thread that's
currently loading periodically checks at the end of each loop).
now, the problem is when one thread sets shouldStopInit to YES and
tries to get the lock. the currently working thread does the
cleaning up and before it unlocks
a third thread sets shouldStopInit to YES and tries to acquire the
lock. how can I make sure that the last thread that tries to enter
will be solely allowed to do so (any previous ones that haven't
started should be ignored)?
It's not clear to me what's going on here. You've got a worker thread
and a GUI thread, what's the third thread?
If you're trying to keep the GUI usable, you shouldn't be doing any
locking in it, unless it's on a lock that's guaranteed to be locked
for a very short amount of time (it sounds to me like you're holding
the lock for longer).
I've implemented things like this in the past by loading the data
into a completely separate data structure and then just switching a
pointer at the critical moment. The
performSelectorOnMainThread:withObject:waitUntilDone:modes: method is
quite useful for this.
- Chris
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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