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 12:00:37 +0200
- Subject: Re: Synchronizing auxiliary mutex data
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx08.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 29C66C05FFDD
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 29C66C05FFDD
- References: <mvmtw3cflej.fsf@suse.de> <1497896660.18410.15.camel@redhat.com> <mvm1sqfdq86.fsf@suse.de>
On Tue, 2017-06-20 at 10:21 +0200, Andreas Schwab wrote:
> On Jun 19 2017, Torvald Riegel <triegel@redhat.com> wrote:
>
> > * 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.
>
> How does it guarantee that the thread calling pthread_mutex_lock see the
> change that the thread calling pthread_mutex_unlock did?
I suppose you are referring to the writes? If so, because of the
unlock/lock synchronization.
> > __count is only accessed within the critical section IIRC.
>
> Same here.
That's not quite the same, because unless I misremember, __count is
protected by the lock: all accesses are within the critical section.