Subj : Re: Memory visibility and the C compiler... ( a bit long )
To   : comp.programming.threads
From : Alexander Terekhov
Date : Thu Jan 13 2005 11:36 am


SenderX wrote:
[...]
>   Externally compiled functions written in 100% assembly language can help
> alleviate the problems associated with the compiler and/or processor
> reordering "critical instructions". Since an assembler will not reorder our
> instructions, we can be assured that everything will be as expected. 

Not everything. Reordering across "critical instructions" (inline asm 
and/or external asm functions) is still possible (and is in fact 
desirable as long as it doesn't break anything). You presume to have 
either stupid optimizers (no IPA and/or full-stop barrier for the
assembly stuff) or really smart ones capable to understand reordering 
constraints embedded in the asm stuff.

[...]
> 2.2 Memory Barriers ...

Your notation for unidirectional constraints sucks. And get rid of 
volatiles. Stick to C++ and atomic<> with member function overloads 
on msync type labels/tags to express reordering constraints. E.g,

  T atomic<T>::swap(T, msync::acq_t) // xchg.acq on Itanic

  ...

  atomic<int> foo;

  ...

  int i = foo.swap(666, msync::acq);

regards,
alexander.

.