Subj : Re: Memory Barriers, Compiler Optimizations, etc.
To   : comp.programming.threads
From : Alexander Terekhov
Date : Fri Feb 04 2005 12:32 pm


Scott Meyers wrote:
> 
> On Wed, 02 Feb 2005 13:01:50 +0100, Alexander Terekhov wrote:
> > > the former, how are programmers in languages like C/C++ expected to make
> > > the association between reads/writes and memory barriers?
> >
> > std::atomic<>
> 
> I'm not sure how to interpret this.  There is no atomic in std, and in
> another post, you described std::atomic as "a dream."  So I don't know
> whether atomic is a template that actually exists and is in widespread use
> or is something that only you use or is something that doesn't actually
> exists in executable form but is rather something you'd like to see exist.

The latter.

[...]

> 
> > > Next, is it reasonable to assume that compilers will recognize memory
> > > barrier instructions and not perform code motion that is contrary to their
> > > meaning?
> >
> > Yep.
> 
> Others have said no.  Can you please explain why you believe that C/C++
> compilers will not perform code motion across memory barriers, especially
> barriers that are not intrinsics but are instead implemented as externally
> compiled functions containing, say, arbitrary assembler?

I meant hypothetical future implementations with atomic<>.

> 
> > I guess you mean
> >
> >   ...
> >   x = a;
> >   y.store(b, msync::rel);
> >
> > It is necessary to have a compiler capable to understand atomic<>
> > and unidirectional reordering constraint associated with its store(T,
> > msync::rel_t) member function.
> 
> Do such compilers exist?  Are they in widespread use?

Not yet.

regards,
alexander.

.