arm, hppa, m68k, sh, nios maintainers: Please check your emulation of atomic operations
Carlos O'Donell
carlos@redhat.com
Fri Nov 11 19:33:00 GMT 2016
On 11/11/2016 12:13 AM, Torvald Riegel wrote:
> These architectures seem to all use various sorts of emulation for
> compare-and-exchange operations (CAS). If these emulations do not stop
> the world during a CAS, or do something else that prevents concurrent
> write operations to the same memory location as the CAS, then atomic
> store operations in glibc need to use a CAS to perform stores.
> Otherwise, concurrent stores can happen between the load(s) and the
> store that the CAS consists of.
>
> If your architecture is affected by this, then it may be possible that
> glibc's current concurrent code does not work correctly; this is because
> we may still have plain stores in places where atomic stores should be
> used. Once we have completed the conversion to C11 atomics, all
> concurrent stores will go through atomic_store_*().
> See Chris Metcalf's patch for tilepro:
> https://sourceware.org/ml/libc-alpha/2016-11/msg00414.html
>
> If your architecture is not affected, I suggest adding a comment why
> that is not the case.
This is an issue on hppa.
We need all concurrent stores to go through atomic_store_*().
The kernel light-weight syscall which emulates CAS can be interrupted by
another thread's store and thus break the CAS. The only thing we prevent
is a signal from the same thread interrupting the CAS, we do this by
not delivering the signal while the thread is in the CAS.
I'll fixup some of the atomic-machine.h bits to make sure we're doing
the most that we can to fix this.
--
Cheers,
Carlos.
More information about the Libc-alpha
mailing list