This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: arch maintainers: RFC on spinlock refactoring
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Chris Metcalf <cmetcalf at mellanox dot com>, Torvald Riegel <triegel at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Cc: Richard Henderson <rth at redhat dot com>, Carlos O'Donell <codonell at redhat dot com>, sjmunroe <sjmunroe at us dot ibm dot com>, David Miller <davem at davemloft dot net>
- Date: Thu, 9 Mar 2017 16:00:40 -0500
- Subject: Re: arch maintainers: RFC on spinlock refactoring
- Authentication-results: sourceware.org; auth=none
- References: <1487442225.20203.99.camel@redhat.com> <853d40d7-c73f-8d46-842f-c82d1cc6d3c0@mellanox.com>
On 03/09/2017 02:32 PM, Chris Metcalf wrote:
> One thing that's important to note is that the above is all about
> TILE-Gx, our more recent 64-bit processor. TILEPro, the older 32-bit
> processor, had only a single atomic operation, a "test and set one",
> which everything else is built on top of using kernel fast syscalls to
> provide CAS and various other simple atomic patterns. I believe this
> is similar to the existing sparc32 atomic support. As a result, on
> TILEPro you have to use "atomic exchange" (via the kernel fast
> syscall) to implement atomic store, since a plain store can race with
> the kernel implementation of atomics. This isn't true on TILE-Gx,
> where an atomic store really can be just a plain store operation.
Right, TILEPro is therefore like hppa in this regard, every atomic
operation has to go into the kernel because you have to use the same
set of locks in the kernel to ensure happens-before between the threads.
--
Cheers,
Carlos.