Re: Problem killing my threads :)
Re: Problem killing my threads :)
- Subject: Re: Problem killing my threads :)
- From: "Ken Thomases" <email@hidden>
- Date: Thu, 26 Sep 2002 07:27:30 -0500
- Priority: normal
On 23 Sep 2002, at 12:58, Aram Greenman <email@hidden> wrote:
>
>
On Monday, September 23, 2002, at 07:58 AM, email@hidden
>
wrote:
>
>
> No, a lock is not required here since you just have a write on one
>
> side and a
>
> read on another one. Both operations will be atomic.
>
>
You should lock even around a simple assignment statement. There is no
>
guarantee that it will be atomic since it can possibly compile to more
>
than one operation. I'm not sure when/if this is the case on PPC, but
>
anyway your code might have to run on a different processor someday.
>
>
I *think* the operation would always be atomic if the variable assigned
>
to was a single-byte type (i.e. char), but I'm not sure.
>
>
Aram
Your caution in the face of multi-threaded shared data access is
admirable, but this is a special case. When:
1) a variable is conceptually boolean in nature, and
2) it is changed in only one direction
it is safe to change it and test it without locking. You are right
that the operation is by no means guaranteed to be implemented as a
single atomic instruction. Furthermore, on multiple-processor
systems it isn't likely to be interlocked. However, none of this
matters.
The variable has some original value (as a typical example, let's say
0). The worker thread is only interested in determining when the
variable changes to no longer have that value (i.e. to be non-zero).
It must not care what specific new value the variable takes on (it
shouldn't test for == 1). Once the variable has been found to have
some other value, the thread doesn't care what subsequent value the
variable may take on -- only the fact that it has _ever_ transitioned
from 0 to non-zero is significant.
So, no matter how the instructions (or partial instructions) of the
two threads are interleaved, eventually the worker thread chooses one
code path or another to follow. If the worker thread chooses to
continue processing, it is conceptually identical to the case where
the worker thread's variable-checking instructions were all executed
before the main thread's variable-setting instructions (i.e. as if
worker thread locks a mutex, worker checks the variable, worker
releases the lock, main thread locks mutex, main thread sets
variable, main thread releases lock). Of necessity, this is a
situation you must tolerate because it is as likely to happen as the
case where the two threads have near simultaneous access to the
variable. You are relying on the worker thread to come back around
and check the variable again at a later time.
Similarly, if the worker thread chooses to terminate because of its
examination of the variable it is conceptually identical to the case
where the main thread completed setting the variable before the
worker thread ever started to check. After all, why would the
variable have any value other than the original if not for the main
thread attempting to set it. Even if the variable doesn't have the
final value that the main thread may eventually get around to storing
into it, it sure isn't the original value (0) so the worker thread
can be certain that the main thread had undertaken to set it.
So, even if the instructions of either thread aren't atomic, the
result is logically atomic. Either the worker thread "saw" the state
as it was before the variable was set (0), or it "saw" the state as
it was after the variable was set (non-0). It can only "see" one
state or the other. There is no intermediate or mixed state.
I point this out because: a) locking mutexes can be expensive, b) to
get the worker thread to terminate promptly, you'll want to check the
variable frequently and hence cheaply, and c) it is a generally
useful technique for this particular common problem in multi-thread
programs.
One caveat: do make sure the variable is declared "volatile" so the
compiler is forced to actually get the variable's value from memory
every time. Otherwise it may optimize by caching it in a register
where the other thread has no way of modifying it at all.
I hope this helps,
Ken
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.