Re: Threads and synchronization
Re: Threads and synchronization
- Subject: Re: Threads and synchronization
- From: Chris Suter <email@hidden>
- Date: Thu, 24 Aug 2006 10:01:50 +1000
This is not the case. OSMemoryBarrier orders memory accesses. On some
architectures (PPC certainly, I don't know about x86), it's possible
that memory stores will be performed in a different order than they
show up in code. So let's say you had this bit of code (it's terrible,
The current incarnation of x86 processors have a slightly stronger
model than PPC processors in that for most instructions, writes will
appear in program order. Remember, however, that reads on both PPC
and Intel can happen in any order. Intel also won't guarantee that
they won't change their memory model for future processors.
For a single variable that you need to force out to memory when you
assign to it, mark it as volatile.
volatile simply disables some of the optimisations the compiler might
perform. A global/heap variable without the volatile keyword will
still end up with the same end value (it might not see some
intermediate writes that the compiler feels it can optimise away).
It's not always necessary to mark your variable as volatile; the
atomic functions (in the absence of a cast) will give you a compiler
warning on passing volatile variables to them so it's worth
understanding when you need volatile and when you don't.
The call to OSMemoryBarrier will *probably* force a store to a
non-volatile variable to be performed, but it's not guaranteed and
that's not its purpose.
Memory barriers do not force anything to go to memory. They just
guarantee the ordering. OSMemoryBarrier will include both a read
memory barrier (all reads before the barrier will be seen to happen
before all reads after the memory barrier) and a write memory barrier
meaning that (all writes before the barrier will be seen to happen
before all writes after the memory barrier). You often don't need to
use OSMemoryBarrier directly since it can often be incorporated into
an OSAtomic...Barrier call that you have nearby. Note that the
OSAtomic... and OSMemoryBarrier calls don't work on 10.3.
(IncrementAtomic et. al are supported though).
If anyone's interested in this stuff they should really read the
processor manuals. The Intel one is called something like IA-32 Intel
Architecutre Software Developer's Manual and it's volume 3A that has
the stuff on multiprocessors.
Whilst I'm at it, I'd like to clarify something said a while back by
Chris Kane:
Locking also ensures visibility of data changes. Generally,
individual processors are not compelled to inform other processors
of changes to data, nor are other processors compelled to pick it
up ( into their L1 cache, say). The real trouble comes when some
changes are noticed and others are not, possibly resulting in what
appears to be an inconsistent state. The special instructions used
by locking also ensure timely and consistent visibility of changes.
Individual processors are compelled to inform other processors of
changes to date and they are compelled to pick the changes up. This
is true for both PowerPC and Intel architectures.
What I think Chris was getting at is that you have to watch the order
in which things become visible to other processors which is where
memory barriers come in.
All this really is interesting (to me anyway), but if you don't need
it, stick with the APIs provided.
- Chris
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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