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: Florian Weimer <fweimer at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>, 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: Mon, 6 Jun 2016 12:48:07 +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>
On 06/03/2016 02:26 PM, Torvald Riegel wrote:
On Fri, 2016-06-03 at 12:03 +0200, Jakub Jelinek wrote:
I guess it is a tough decision. If you don't have HW instruction to read
say double word aligned integer atomically, if you don't implement atomic
load on it through compare and swap (which indeed won't work with read-only
memory), then you probably need to fall back to locks in libatomic.
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.
It's possible to do this (in an ABI-compatible fashion even) with kernel
support. I doubt it makes sense to try to fix this with lock fallback
(which breaks in so many unexpected ways).
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
The performance problem is difficult to address, of course. Kernel
emulation likely isn't cheap at all.