[cpp-threads]atomic operations package

[Alexander Terekhov]

On 8/23/05, Boehm, Hans <hans.boehm at hp.com> wrote:
> Doesn't msync::ddhlb just turn into acquire, and msync::ssb into
> release?  Thus I think the only issue here is a possible
> performance loss.

Yes, but that was the point. And the loss is quite real on archs like 
Power (lwsync or isync do take some cycles and ddhlb is for free, for
example) and Sparc (reportedly hypothetical RMO): 

http://groups.google.ca/group/comp.programming.threads/msg/8bdc77efe247226c

"the change in membars gave about a 7% performance improvement 
on UltraSparc IIs".

That change is about reliance on implied constraint (hoist barrier) 
for dependent stores. But even with compiler injected fake control 
dependency, you'd still have to include MEMBAR #LoadLoad (under
RMO) for stuff like DCSI with full acquire instead of mere ddhlb.

> 
> There are issues here where I think we still have choices that should
> be discussed:
> 
> 1) You make the ordering constraint a run-time parameter, and I make
> it a member template parameter.  My guess is that you almost never want
> it to be a runtime parameter.  

It's not really meant to be a run-time parameter. It just takes a bit 
less characters and is more readable IMO.

http://www.terekhov.de/pthread_refcount_t/experimental/refcount.cpp

op<contraint>();

vs

op(contraint);

I mean.

regards,
alexander.