This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCHv2] powerpc: Spinlock optimization and cleanup
- From: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "rth at twiddle dot net" <rth at twiddle dot net>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Steve Munroe <sjmunroe at us dot ibm dot com>
- Date: Thu, 01 Oct 2015 21:35:47 +0200
- Subject: Re: [PATCHv2] powerpc: Spinlock optimization and cleanup
- Authentication-results: sourceware.org; auth=none
- References: <560C0DA6 dot 5060409 at linux dot vnet dot ibm dot com> <560CFA64 dot 2030205 at arm dot com> <1443727026 dot 30828 dot 413 dot camel at localhost dot localdomain> <20151001192718 dot GJ8645 at brightrain dot aerifal dot cx>
On Thu, 2015-10-01 at 15:27 -0400, Rich Felker wrote:
> On Thu, Oct 01, 2015 at 09:17:06PM +0200, Torvald Riegel wrote:
> > > (the issue is that for correct pthread_spin_trylock behavior
> > > the lock should be seqcst instead of acquire and the unlock
> > > should be release instead of barrier+store otherwise trylock
> > > can spuriously report locked state).
> >
> > Right now, unlock is a full barrier (ie, seqcst) plus store. That is
> > stronger than a release store. Also note that a failing POSIX
> > synchronization function is not supposed to synchronize memory. So, a
> > failing trylock doesn't help a program unless it synchronizes through
> > some other way, in which case this other way will "provide" the
> > barriers.
>
> As always, the issue is not whether it synchronizes memory on failure,
> but whether it can accurately determine whether to fail or not without
> synchronizing memory. The latter is an implementation detail of
> course, but in practice you can't make this determination without
> synchronizing memory.
Sticking to our example here, you can determine this. When you do a
memory_order_relaxed load as part of a trylock implementation, for
example, you "pick a position" in happens-before that represents always
a valid observation of state from this thread's perspective. The
question is whether you make guarantees to your caller about your
observation and what it might mean for something else, or not.