Re: question: NSThread & NSLock
Re: question: NSThread & NSLock
- Subject: Re: question: NSThread & NSLock
- From: Karim Morsy <email@hidden>
- Date: Mon, 29 May 2006 14:51:57 +0200
Hi Chris,
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?
no, every time the user selects an audio file one thread is detached
that performs the initialization. that thread finishes execution as
soon as he leaves the critical section and notifies the main thread.
this works fine.
in case the user decides to load a different file while the thread
hasn't finished loading, a new thread is detached and tries to
acquire the lock. the thread that has been running stops its regular
control flow, cleans up , releases the lock and the
thread that has been waiting enters and loads the newly selected file.
this case also works fine.
things start getting problematic when one thread is loading, and the
user clicks twice on a different audio file (within a short period of
time).
while the first thread is still cleaning up and hasn't unlocked, 2
threads have been detached and try to enter. I only want the user's
last selection to take effect.
(the gui is not affected by the locking).
I haven't been able to come up with an ideal solution for this.
thanks,
Karim
On May 29, 2006, at 1:40 PM, Chris Suter wrote:
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
_______________________________________________
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