Re: Question about Threading
Re: Question about Threading
- Subject: Re: Question about Threading
- From: Michael Becker <email@hidden>
- Date: Wed, 10 Aug 2005 18:27:11 +0200
Am 10.08.2005 um 17:55 schrieb Chris Kane:
On Aug 8, 2005, at 7:14 AM, Cameron Hayne wrote:
On 8-Aug-05, at 8:39 AM, Michael Becker wrote:
I have created a (class-wide) boolean variable which the thread
checks on each iteration to see whether it may continue or not.
However, I get synchronizing problems: When I set that boolean
variable to STOP the thread, how can I make sure that I wait
until the thread has finished its current iteration and then exited?
What (in general) is the best way of doing things like that?
You want to use NSLock.
You might find it useful to look at my example project "ImageCalc"
that illustrates use of NSLock:
http://hayne.net/MacDev/ImageCalc/
I'm not saying the above example does this, just providing the
following warning...
Don't, however, try to solve the synchronization and "wait until
the background thread is done" by locking a lock in one thread
which the other thread unlocks. That invokes undefined behavior in
the underlying POSIX lock objects, and is a bad idea. I warn about
this because it is tempting to do because it seems simple. One
should never use mutex locks to implement "conditional waiting" is
the point; that is, never use -lock on a mutex in a "block until
something happens" sense, where the event is signalled by some
other thread (obviously, since the current thread is now blocked on
the lock) unlocking the previously locked lock.
That exactly was my initial problem: Telling my image-loading thread
to exit (I do so via a global BOOL variable) and then wait until it
actually did finish before I go on. I solved this issue via
CoreServices' semaphore API. After I set the global bool variable to
stop the thread I use an MPWaitOnSemaphore( ) to wait for the signal
sent by the thread right before it exits.
Do I have to be aware of any hazards here?
Regards,
Michael
_______________________________________________
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