[cpp-threads] Atomic operations and memory barriers

[Nick Maclaren]

Thinking about it, I realise that there is one very fundamental
point where there may be confusion.

Let us start from the position that atomic operations do not imply
a memory barrier.  Not a problem.  But some of the previous messages
imply that they could move over one.  If that is permitted, it is a
catastrophic mistake.  Yes, that bad :-(

Every form of 'barrier' defines a partial ordering.  Atomic operations
define a dynamic one, which orders all atomic operations, not necessarily
in abstract machine order.  Sequence points are yet another form of
partial ordering.

I assert that it is critical that the standard does not allow these
various partial orderings to be incompatible with each other, because
that will (a) confuse the hell out of 99% of all known users and
(b) make program validation damn-near impossible.

Given the current wording of sequence points, I don't see how that
can be done unless at least accesses to volatile are constrained to
not move across memory barriers.

Allowing atomic operations to move across them means either permitting
incompatible partial orderings or putting a LOT of effort into creating
some suitable constraints.  Let's consider a SIMPLE example:

Thread A:
    x = 123
    ATOMICALLY y = x
    z = y
    BARRIER TO THREAD B

Thread B:
    BARRIER FROM THREAD A
    Is it possible for x = z = 123 != y?

So what I would say is, allow atomic operations to move, but say that
they are still bound by memory barriers.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679