This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Synchronizing auxiliary mutex data
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 20 Jun 2017 19:39:57 +0200
- Subject: Re: Synchronizing auxiliary mutex data
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=triegel at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com F2DBD7F6A6
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F2DBD7F6A6
- References: <mvmtw3cflej.fsf@suse.de> <1497896660.18410.15.camel@redhat.com> <mvmshiubt3j.fsf@suse.de>
On Tue, 2017-06-20 at 17:02 +0200, Andreas Schwab wrote:
> On Jun 19 2017, Torvald Riegel <triegel@redhat.com> wrote:
>
> > __owner accesses need to use atomics (which they don't, currently).
>
> Does that mean mutexes are broken right now?
No, I would not characterize it like that. Technically, this is
undefined behavior because the program is not data-race-free. However,
all we'd need for the accesses to __owner are relaxed MO atomics, so on
the architectures we care about it's sufficient if the compiler just
does the access once without splitting it up into different parts; we
can assume that it is very likely that it will do that in practice.
We should avoid the undefined behavior eventually, but it is nothing
that I'd be really worried right now.