From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-09-20 17:02:05
Alexander Terekhov <terekhov_at_[hidden]> wrote:
> Matt Hurd wrote:
> > > >> But why is a concurrent-aware setter useful if its effects aren't
> > > >> visible to the other threads?
> > > >
> > > > In what way do you mean they not visible?
> > > >
> > > > Such aligned memory operations are guaranteed to be atomic on ia32 at
> > > > a system wide level AFAIK.
> > >
> > > On IA32, sure, but not on other architectures.
> > Yup. Which gets back to the subject line...
> On IA32,
> - stores have release semantics (sink-load/store mbar for
> preceding loads/stores in the program order);
> - loads have acquire semantics (hoist-load/store mbar for
> subsequent loads/stores in the program order);
> - lock instructions have compound release and acquire semantics
> (fully fenced).
> See Plan9 story for an illustration of lockless stuff that
> needs store-load fence (compound sink-store and hoist-load mbar)
> on IA32.
> (Subject: std::msync)
Always insightful, thanks Alexander. However, I'm not talking about
guarantees of ordering or timing, just "eventual" visibility.
Avoiding a lock/fence where possible is a good thing if appropriate,
though as you show the subtleties are not to be underestimated. The
type trait needs_lock<T> would provide you with a cue to memory
transaction atomicity. Timely availability and ordering, as you show,
are different beasts. Perhaps a better name would be
boost::memory_atomic<T> as needs_lock is almost as misleading as
By the way, when you say ia32 which architectures are you referring
to, as they have varied quite a bit on their capabilities from 386 to
P4 & Xeon?
Do you have a view on the original question about how to structure
code regarding architecture specific specializations?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk