Re: questions about memory_order_seq_cst fence

Alexander Terekhov <terekhov@xxxxxx> writes:

Anthony Williams wrote:

Alexander Terekhov <terekhov@xxxxxx> writes:

Anthony Williams wrote:

Masakuni Oishi <yamasa@xxxxxxxxxxxx> writes:

If so, for the code 1 in my first post, is the outcome
r1 == 0 && r2 == 1 && r3 == 0 possible on IA-64?

I believe so.

Perhaps this is relevant:

See Total ordering of WB Releases.

(remote write atomicity)

Maybe I'm wrong; I am not an expert on IA-64 semantics.

Suppose that I can program in terms of C++MM's acquire/release. The
platform is x86.

How am I supposed to ensure remote write atomicity ala IA-64 releases
for a particular store (relevant loads) using C++MM and NOT pessimizing
everything to seq_cst?

In the general case, you can't. Acquire/release is essentially pairwise
synchronization in the C++0x MM; if you need a total order then you must
use seq_cst.

However, in particular cases then you can order particular subsets. If
you have an example of code that you would like to work then I can see
if I can think of a way to make it work without using seq_cst everywhere.

The next question is regarding store-load fencing for particular
release-store and subsequent acquire-load.

One issue here is that the terminology and effects of SPARC membar
constraints do not map cleanly onto C++0x ordering constraints. SPARC
membar constraints relate instruction order to global visibility
order. C++0x ordering constraints are transitive pairwise constraints
between processors, apart from seq_cst which is a global ordering on
seq_cst operations.

Consequently there is not always a simple 1-1 translation between the
two, but you should be able to achieve the same effects. If there are
cases where you can't, then I am interested to understand the issues,
and see how the C++ MM could be extended to handle the new cases.

Author of C++ Concurrency in Action
just::thread C++0x thread library
Just Software Solutions Ltd
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976