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
