Re: Prototype libatomic

[Torvald Riegel <triegel at redhat dot com>]

On Wed, 2012-03-14 at 14:14 -0400, Andrew MacLeod wrote:
> I expect in the not too distant future other sorts of guarantees may be 
> desired, such as various forms of forward progress guarantees to replace 
> the spin locks

I will have a look at what's there, and can take care of the lock-based
fallbacks if you want.

Note that if we really want to look at progress guarantees again, we'll
also have to consider:
- how C++11 locks are implemented
- how strong CAS is implemented on LL/SC architectures
- how various (strong) atomic operations are implemented using CAS loops
It might also mean that we have to take the OS scheduler's guarantees
into account (so, do different things on different platforms).


> and It'd be nice to have a TM version of the library as 
> well, so when hardware is available we can make good use of it.

I don't think we should put a lot of effort into this right now because
I don't see enough use cases for TM in libatomic.  Typically, accessing
more than one object atomically is the hard part in concurrent
programming, not accessing a bigger-than-word-sized object atomically.
With first-generation HTMs that don't have minimum capacity/progress
guarantees, we can't guarantee more than a lock-based fallback anyway.
If a programmer assumes that HTM is available, why not use transactions
in the first place?

Also, architectures with HTM support will likely have a full set of
word-sized atomic operations too.

If we actually see that users want have low-level atomic access to
larger-than-word-sized and don't want to use locks or transactions for
it, we can still add HTM support to libatomic.


Torvald