Re: [PATCH] Add compiler barriers around modifications of the robust mutex list.

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2017-01-13 at 20:44 +0100, Florian Weimer wrote:
> On 01/13/2017 12:21 PM, Torvald Riegel wrote:
> > On Fri, 2017-01-13 at 10:45 +0100, Florian Weimer wrote:
> >> On 12/24/2016 12:57 AM, Torvald Riegel wrote:
> >>>
> >>>     	* nptl/descr.h (ENQUEUE_MUTEX_BOTH, DEQUEUE_MUTEX): Add compiler
> >>>     	barriers and comments.
> >>>     	* nptl/pthread_mutex_lock.c (__pthread_mutex_lock_full): Likewise.
> >>>     	* nptl/pthread_mutex_timedlock.c (pthread_mutex_timedlock): Likewise.
> >>>     	* nptl/pthread_mutex_unlock.c (__pthread_mutex_unlock_full): Likewise.
> >>
> >> Would you please rebase this patch on current master and repost?  Thanks.
> >
> > Attached is a patch that is on top of the rebased patch that removes the
> > robust mutex assembly code.
> 
> I'm wondering if the memory barriers are too strong.  We only need to 
> make sure that all writes happen before the barrier.  If we can get 
> weaker barriers, maybe we can put them into the macros themselves?

They are too strong, but (1) I doubt it makes much of a performance
difference, (2) any weaker barriers would require compiler support we
don't really have right now AFAIK, and (3) weaker barriers can be used
once we have atomic_signal_fence_release(), for example (so after the
cleanup work that converts robust mutexes to use C11-style atomics.
IOW, just wait a little :)

> I didn't see any regressions with build-many-glibcs.py, and the test 
> suite still passes on armv7hl-redhat-linux-gnueabi, which lacks the prev 
> field in the robust list.

Thanks for testing.  I will commit this patch then.