On Thu, Jan 31, 2019 at 12:55:18AM +0100, Thomas Gleixner wrote:
> On Wed, 30 Jan 2019, Paul E. McKenney wrote:
> > On Thu, Jan 31, 2019 at 12:13:51AM +0100, Thomas Gleixner wrote:
> > > I might be wrong as usual, but this would definitely explain the fail very
> > > well.
> >
> > On recent versions of GCC, the fix would be to put this between the two
> > stores that need ordering:
> >
> > __atomic_thread_fence(__ATOMIC_RELEASE);
> >
> > I must defer to Heiko on whether s390 GCC might tear the stores. My
> > guess is "probably not". ;-)
>
> So I just checked the latest glibc code. It has:
>
> /* We must not enqueue the mutex before we have acquired it.
> Also see comments at ENQUEUE_MUTEX. */
> __asm ("" ::: "memory");
> ENQUEUE_MUTEX_PI (mutex);
> /* We need to clear op_pending after we enqueue the mutex. */
> __asm ("" ::: "memory");
> THREAD_SETMEM (THREAD_SELF, robust_head.list_op_pending, NULL);
>
> 8f9450a0b7a9 ("Add compiler barriers around modifications of the robust mutex list.")
>
> in the glibc repository, There since Dec 24 2016 ...
>
> So the question is whether this is sufficient. That ordering only only
> matters vs. the thread itself and not for others.
Ah, in that case you can use __atomic_signal_fence(__ATOMIC_RELEASE)
instead of the __atomic_thread_fence(__ATOMIC_RELEASE).
The __atomic_thread_fence(__ATOMIC_RELEASE) provides ordering between
threads, but __atomic_signal_fence(__ATOMIC_RELEASE) only does so
within a thread.
Thanx, Paul
