Regardless, you need to protect your use that shared variable with
a lock or other synchronization primitive. Doing so will ensure
the compiler doesn't optimize it out or keep its value solely in a
register (which means it won't be shared between the two threads),
and is also simply correct multithreaded programming practice.
The "volatile" keyword on the variable may be enough in this case.
(I don't remember the OP's question; I'm just reading between the
lines.)
The "volatile" keyword -- while it may be imbued with a certain
meaning on certain platforms -- is not necessarily going to have the
same meaning across platforms, compilers, and time (e.g. compiler, OS,
and hardware versions). Its definition is left quite open in the
standard relative to what people seem to expect it to mean.
For example, a platform *could* interpret "volatile" to mean "must
always store to memory." But what does that really mean? After all,
on some multi-processor platforms that won't be sufficient for
synchronization. A store to memory may just write to cache and be
scheduled by the processor hardware, and not actually go across the
bus until some point later where it would be snooped by the other
processors and used to update their own cached values, if any. Thus
if your threads happen to be running on different processors on such a
system, just using "volatile" would *not* cause them to synchronize
properly. (I believe the original BeBox -- which used a pair of
PowerPC 603 CPUs, which didn't have any native multiprocessor support
-- was just such a platform.)
This is why it's *always* better to use locks or other synchronization
primitives such as atomic-increment and atomic-compare-and-set when
writing multithreaded code. By using a synchronization primitive,
you're explicitly stating that you intend for some particular data to
have the potential to be accessed by multiple flows of control,
possibly on different processors, and the operating system, libraries,
compiler implementation, etc. can take appropriate measures on your
behalf to ensure that this access works as intended.
If you try to second-guess your runtime environment -- for example, by
just using "volatile" and hoping that it does the right thing -- you
*will* end up getting it wrong eventually, because the C memory model
isn't defined in a way that guarantees you can always get it right in
all situations.
-- Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
