[cpp-threads] A question about N2153

Paul E. McKenney paulmck at linux.vnet.ibm.com
Wed Jan 17 20:32:03 GMT 2007


On Wed, Jan 17, 2007 at 11:56:29AM -0800, Chris Thomasson wrote:
> ----- Original Message -----
> From: "Paul E. McKenney" <paulmck at linux.vnet.ibm.com>
> To: "C++ threads standardisation" <cpp-threads at decadentplace.org.uk>
> Sent: Wednesday, January 17, 2007 11:20 AM
> Subject: Re: [cpp-threads] A question about N2153
> 
> 
> >On Wed, Jan 17, 2007 at 08:44:00PM +0200, Peter Dimov wrote:
> >>What is the reference implementation of acquire_fence for x86, SPARC RMO,
> >>PowerPC, IA-64? I'm guessing (no op), #LoadLoad | #LoadStore, lwsync, mf.
> >
> >Stupid side question...  Why acquire_fence and release_fence?  This is
> >the only group I have come across that uses these.  Where I come from,
> >we use the following types:
> 
> Well, an acquire_"fence" is like this:
> 
> // do your atomic operation here
> #StoreLoad | #StoreStore
> 
> And a release_"fence" is like this:
> 
> #LoadStore | #StoreStore
> // do your atomic operation here

OK.  But I already understood what you guys meant by these two primitives.
My question is why choose these particular definitions?  From my
viewpoint, the definitions are quite strange, and they don't do what I
want in many cases.  I often need a StoreStore without the StoreLoad, and
I often need to enforce data dependencies.  This latter especially is not
supported well by the cpp-threads definitions, as most CPUs don't need any
barriers in that case (just disable compiler code-motion optimizations).

Thoughts?

						Thanx, Paul



More information about the cpp-threads mailing list