Re: Implementing atomic load as compare-and-swap for read-only memory

[Torvald Riegel <triegel at redhat dot com>]

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.