[cpp-threads] atomic operations package

[Peter Dimov]

Doug Lea wrote:

[About acquire/release only vs fine grained]

> I think this is fine. I know that neither Peter Dimov nor
> Alexander Terekhov think this suffices to support usages
> they say they need. (Which is the main reason I gave up
> on variants of this.)
>
> Peter and/or Alexander: Could you soon post something
> (re)stating your concerns so we can make a decision about it
> rather than continuing to stall?

I'm slowly gravitating towards the acq/rel model.

One argument in favor of the load only variants was 
pthread_rwlock_rdlock/unlock. It's not clear whether the current POSIX 
memory model permits it, but under the assumption that it does, read locks 
and read unlocks do not need to constrain writes.

But I found an example where the more constrained rwlock (with plain 
acquire/release on read lock/unlock) would be useful, whereas the optimized 
version would actually decrease performance.

Consider a mostly lock-free data structure where most operations (insert, 
delete, find) can proceed in parallel, but some (resize) need exclusive 
lock. It's natural to use a rwlock for that; a rwlock is not about reads or 
writes, it's about shared and exclusive access.

This leaves me with one other use of the fine-grained constraints - 
expressing bidirectional (SPARC RMO-style) barriers. A #loadStore, for 
instance, can be expressed as msync_slb + msync_hsb (prevent sinking of 
loads, hoisting of stores.) The acquire/release model can only express a 
full fence.