86c
Subj : questions re: atomic<>
To   : comp.programming.threads
From : Sean Kelly
Date : Fri Jun 24 2005 12:17 pm

I've gotten to the point where I think I mostly understand memory
visibility and such, but a few issues have me wondering if I've gotten
it wrong.  First, it seems that all the basic msync methods (hlb, hsb,
slb, ssb) are intended to ensure that the executing processor doesn't
do any instruction reordering that it shouldn't, so a carefully written
algorithm can't be undermined by aggessive pipelining.  Second, (on the
architectures I know about) memory visibilty is handled automatically
by the cache coherency mechanism, so once a memory store occurs the new
value will be immediately visible to all processors--old cached values
will be refreshed, etc.  This all seemed to make sense until the more
recent addition of msync::slfence, as I can't envision an algorithm
where I'd want to prevent a processor from reordering its stores below
its loads, or vice-versa (since a processor cache is always consistent
with itself).  I can only conclude that this particular mechanism means
"wait for pending writes from ALL processors to complete before
beginning the following reads," so I'm wondering about my original
assumption that the original (hlb, hsb, ...) instructions never
actually propogate beyond the executing processor.  And by the same
token, the LOCK instruction on IA-32 definately seems to force a global
memory sync of sorts.  Am I right in concluding, then, that some msync
instructions are local to the executing processor while some have a
more wide-reaching effect?  If I use msync::mfence, might this just
prevent isntruction reordering on one architecture while it would force
a full bus sync on another (IA-32)?

As a semi-related issue, I'm wondering if the use of sfence/lfence has
changed for the Itanium vs. the classic IA-32 architecture.  As far as
I know, the fence instructions were limtied to ordering streaming
operations on IA-32, but I could have sworn I read something about LOCK
being deprecated for the Itanium (I wish I could find the reference
now).


Sean

.

0