[cpp-threads] Visibility question

Peter Dimov pdimov at mmltd.net
Wed Aug 2 21:11:47 BST 2006


Boehm, Hans wrote:
> We agree that there is clearly no race in the fence() case.
>
> But I think that's a fundamentally different question, since in my
> view fence() itself introduces synchronization edges between
> consecutively executed (in some total order) fence() operations.  I
> think it has to. Otherwise consider:
>
> Thread 1:
> x.store<raw>(1);
> fence();
> r2 = y.load<raw>();
>
> Thread 2:
> y.store<raw>(1);
> fence();
> r2 = x.load<raw>();
>
> Undesirable outcome: r1 = r2 = 0
>
> There is nothing to prevent this unless something introduces a
> synchronization edge between threads to make a store appear "in
> between" the initialization and the raw load.
>
> (I suspect there are interesting issues as to what fence() really
> means and how it interacts with atomics.  But I think the weakest
> semi-plausible interpretation is that fences behave as though they are
> both load and store operations on some locations shared by all
> fences.)
>
> The fetch_add operations on the other hand operate on distinct
> locations, and hence introduce no inter-thread happens-before edge.

Question:

Is a program that only uses <ordered> accesses sequentially consistent?

How does the answer follow from the formal description of the memory model? 
I was unable to deduce it myself.




More information about the cpp-threads mailing list