RE: [boost] Re: platform specific structures

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2004-09-21 07:12:22

Matt Hurd <matt.hurd_at_[hidden]> wrote:
> 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.
> > 
> > http://groups.google.com/groups?selm=414E9E40.A66D4F48%40web.de
> > (Subject: std::msync)
> > 
> > regards,
> > alexander.
> 
> Always insightful, thanks Alexander.  However, I'm not talking about
> guarantees of ordering or timing, just "eventual" visibility.

If a change to a variable is not followed by what the compiler sees as
a release then the change could perhaps be moved into a following
critical section, resulting in deadlock.  See the last paragraph of
<http://groups.google.com/groups?selm=409A193B.7DD71861%40xemaps.com>
(further up the thread Alexander pointed at).

Note also that the compiler could also hoist the test of the control
variable out of the loop if it can tell that nothing in that loop
will modify the control variable.  This seems to me to be a more likely
problem.

It is possible that "volatile" may help you to ensure visibility, but
the semantics of volatile are implementation-dependent and not well
specified.

<snip>
> 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?
<snip>

The ordering guarantees remain much the same though the atomicity
guarantees have become stronger as the bus width increased from 16
bits (386SX) to 32 and 64 bits.

Ben.