This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SH runtime switchable atomics - proposed design
- From: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Oleg Endo <oleg dot endo at t-online dot de>, gcc at gcc dot gnu dot org, musl at lists dot openwall dot com
- Date: Thu, 21 Jan 2016 12:22:08 +0100
- Subject: Re: SH runtime switchable atomics - proposed design
- Authentication-results: sourceware.org; auth=none
- References: <20160119202851 dot GA18720 at brightrain dot aerifal dot cx> <1453331298 dot 3681 dot 58 dot camel at t-online dot de> <20160121012229 dot GT238 at brightrain dot aerifal dot cx>
On Wed, 2016-01-20 at 20:22 -0500, Rich Felker wrote:
> On Thu, Jan 21, 2016 at 08:08:18AM +0900, Oleg Endo wrote:
> > Do you have plans to add other atomic operations (like
> > arithmetic)?
>
> No, at least not in musl. From musl's perspective cas is the main one
> that's used anyway. But even in general I don't think there's a
> significant advantage to doing 'direct' arithmetic ops without a cas
> loop even when you can (with llsc, gusa, or imask model). With gusa
> and imask the only time you benefit from not implementing them in
> terms of cas is on the _highly_ unlucky/unlikely occasion where an
> interrupt occurs between the old-value read before cas and the cas.
> For llsc there's more potential advantage because actual smp
> contention is possible, but sh4a is probably not a very interesting
> target anymore.
Things like atomic increments are combinable, so you can make them scale
better. You can do combining too with CAS, but if you're using the CAS
to implement an increment, the program would have to issue another CAS,
so you're not gaining as much.