This is the mail archive of the
mailing list for the GCC project.
Re: Implementing atomic load as compare-and-swap for read-only memory
- From: Torvald Riegel <triegel at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>, gcc at gcc dot gnu dot org, Richard Henderson <rth at redhat dot com>
- Date: Fri, 03 Jun 2016 15:36:38 +0200
- Subject: Re: Implementing atomic load as compare-and-swap for read-only memory
- Authentication-results: sourceware.org; auth=none
- References: <57514F17 dot 2090007 at foss dot arm dot com> <20160603100300 dot GE7387 at tucnak dot redhat dot com> <1464956769 dot 17104 dot 295 dot camel at localhost dot localdomain> <20160603123226 dot GH7387 at tucnak dot 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