Re: Question about Threading
Re: Question about Threading
- Subject: Re: Question about Threading
- From: Chris Kane <email@hidden>
- Date: Wed, 10 Aug 2005 10:46:05 -0700
On Aug 10, 2005, at 9:27 AM, Michael Becker wrote:
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?
That sounds like it would be fine.
Chris Kane
Cocoa Frameworks, Apple
_______________________________________________
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