Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Alexander Terekhov <terekhov@web.de>
Newsgroups: comp.programming.threads
Subject: Re: questions about memory_order_seq_cst fence
Date: Tue, 21 Jun 2011 18:37:18 +0200
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <4E00C8BE.4A910747@web.de>
References: <43eb372b-6517-4914-b647-860f1f7136ba@k15g2000pri.googlegroups.com> <87tybsm5kq.fsf@justsoftwaresolutions.co.uk> <35ec803e-2871-41ce-97ea-8b615b29050f@r33g2000prh.googlegroups.com> <87hb7r5z03.fsf@justsoftwaresolutions.co.uk> <87fwnafd9j.fsf@justsoftwaresolutions.co.uk> <4358686f-7bfb-480e-ae71-a8ce57566ab0@l14g2000pro.googlegroups.com> <871uyuasc0.fsf@justsoftwaresolutions.co.uk> <4DFCAB39.35CDACC8@web.de> <87oc1ssyaq.fsf@justsoftwaresolutions.co.uk> <4DFF4B71.20A46979@web.de> <871uyosiuw.fsf@justsoftwaresolutions.co.uk> <4E009468.4B9FF511@web.de>
Reply-To: terekhov@web.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: mx04.eternal-september.org; posting-host="MCbSEzW5qwGLFMNXJh39IQ"; logging-data="22543"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX189C2uzvLELC5W7b2tFXIAdjq8fDT2m+Zg="
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
Cancel-Lock: sha1:W2KE+Gm5gNPwV2T8RRgcEQHJ3xk=
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:347


Alexander Terekhov wrote:
> 
> Anthony Williams wrote:
> [...]
> > > 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.
> 
> I have no problem using seq_cst for either particular store or relevant
> loads ... 

I take that back. I'd rather get rid of seq_cst altogether.

atomic<>'s loads and stores ought to support the following 'modes':

  Whether load/store is competing (default) or not. Competing load 
  means that there might be concurrent store. Competing store means 
  that there might be concurrent load or store. Non-competing 
  load/store can be performed non-atomically.

  Whether competing load/store needs remote write atomicity (default 
  is no remote write atomicity). All competing loads/stores must 
  specify the same remote write atomicity mode.

  Whether load/store has specified reordering constraint (default 
  is no constraint specified) in terms of the following reordering 
  modes:

    Whether preceding loads (in program order) can be reordered 
    across it (can by default).

    Whether preceding stores (in program order) can be reordered 
    across it (can by default).

    Whether subsequent loads (in program order) can be reordered 
    across it (can by default). For load, the set of constrained 
    subsequent loads can be limited to only dependant loads (aka 
    'consume' mode).

    Whether subsequent stores (in program order) can be reordered 
    across it (can by default). For load, there is an implicit 
    reordering constraint regarding dependent stores (no need to 
    specify it).

    atomic<>'s fence operation can be used to specify reordering 
    constraint using the same modes.

regards,
alexander.