On Fri, 2016-06-03 at 14:32 +0200, Jakub Jelinek wrote: > On Fri, Jun 03, 2016 at 02:26:09PM +0200, Torvald Riegel wrote: > > And that would be fine, IMO. If you can't even load atomically, doing > > something useful with this type will be hard except in special cases. > > Also, doing a CAS (compare-and-swap) and thus potentially bringing in > > the cache line in exclusive mode can be a lot more costly than what > > users might expect from a load. A short critical section might not be > > much slower. > > > > If you only have a CAS as base of the atomic operations on a type, then > > a CAS operation exposed to the user will still be a just a single HW > > CAS. But any other operation besides the CAS and a load will need *two* > > CAS operations; even an atomic store has to be implemented as a CAS > > loop. > > Would we just stop expanding all those __atomic_*/__sync_* builtins inline > then (which would IMHO break tons of stuff),
I agree that switching from atomic HW instructions to lock-based atomics or vice versa is an ABI break. I'm not quite sure whether to be more concerned about this or about storing to read-only memory. Using read-only memory is only meaningful if the pages are also mapped by another process that has write access to them, but maybe that's more common than we'd think? OTOH, having that and having use of wide atomics might be rare? > or just some predicate that > atomic.h/atomic headers use? Not sure which predicate you mean precisely, but if it's about not advertising operations as lock-free that use weird things like CAS for loads, then I'd probably agree. I believe that many users understand "lock-free" to also imply that they are natively supported by the hardware (and also efficiently, not generating unncessary contention), so not advertising load-based-on-CAS as lock-free might be helpful to them.
