Subj : Re: Memory Barriers, Compiler Optimizations, etc.
To   : comp.programming.threads
From : Scott Meyers
Date : Thu Feb 03 2005 08:23 pm

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.
My question was not rhetorical.  From other postings in this thread, I get
the impression that what C/C++ programmers actually do is call
compiler-specific intrinsics or externally compiled functions (possibly
implemented in assembler) that bundle reads/write and membars together,
then trust that their build systems (i.e., compilers/linkers/runtime
systems) won't unbundle and reorder things such that the semantics of the
system are changed.  Do you disagree with this?

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

Scott

.