On 5/29/06 5:51 AM, "Karim Morsy" <email@hidden> wrote:
> 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
> 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.
The problem is that the message sent to stop the current thread is not
clearly addressed to the specific thread that should stop. Most of the time
the intended recipient of the stop message is clear - since there is only
one thread that thinks it is the active thread. But as soon as more than one
thread must be stopped in a short amount of time - then it is no longer
clear to which thread this stop message is being directed - and at that
point there is a problem.
So instead of broadcasting that the "current" thread should stop, the
program would do better to broadcast which thread should be the one running.
So instead of a boolean variable, a thread ID variable would specify the
thread ID of last released thread - the thread that should be running in
response to the user's latest action. So the current thread would poll this
variable to confirm that its thread ID matched the thread ID stored therein.
And if they did not match, then some other thread would be the one that
should be running and therefore this thread would know to clean up and
surrender the lock.
Note that reading and writing this thread id variable should use atomic
functions (see OSAtomic.h). Doing so will help prevent false comparisons
owing to concurrent updates and accesses.
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