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: Mon, 19 Jun 2017 20:24:20 +0200
- Subject: Re: Synchronizing auxiliary mutex data
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx05.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 6F90B19CBF6
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6F90B19CBF6
- References: <mvmtw3cflej.fsf@suse.de>
On Mon, 2017-06-19 at 10:10 +0200, Andreas Schwab wrote:
> What is synchronizing the auxiliary data in pthread_mutex_t.__data
> (__owner and __count) between threads?
__owner accesses need to use atomics (which they don't, currently).
Relaxed MO is fine I believe:
* We write to __owner only when in the critical section, with relaxed
MO; we write TID after lock and 0 before unlock. Those writes are
ordered by the critical section.
* There are reads outside of the critical sections, but those need to
read-from either the most recent (in modification order) store by the
same thread, or a more recent store by another thread; so, you can't
read your TID unless you're in the critical section because if you are
not, you will read 0 or another TID.
__count is only accessed within the critical section IIRC.
Is that what you were asking about?