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.
Ok, If you have a global variable that indicates which thread should
be running, you can terminate the others if their thread ID differs.
It won't matter if the other threads acquire the lock briefly.
You could also optimise it so that if you've got a thread already
running, it takes up new requests but you need to be careful with
Also, as I suggested in my previous post, I would think about getting
rid of the lock and loading the data into a separate data structure
swapping a pointer upon completion.
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