This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: powerpc pthread_once bug fix
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: munroesj at us dot ibm dot com, Alan Modra <amodra at gmail dot com>, libc-alpha at sourceware dot org, rsa at linux dot vnet dot ibm dot com
- Date: Thu, 30 Aug 2012 16:09:47 -0500
- Subject: Re: powerpc pthread_once bug fix
- References: <20120711113606.GM3117@bubble.grove.modra.org> <503FB9AA.7000708@redhat.com> <1346357129.4800.10.camel@spokane1.rchland.ibm.com> <503FC962.5000305@redhat.com>
- Reply-to: munroesj at us dot ibm dot com
On Thu, 2012-08-30 at 14:13 -0600, Jeff Law wrote:
> On 08/30/2012 02:05 PM, Steven Munroe wrote:
> > Since Alan is a sleep I will try to the answer. =M should imply the
> > memory clobber but it would not hurt to be explicit. lwarx/stwcx. are
> > index forms and r0 as the 2nd parm implies no index, just a base address
> > in the 3rd register parm. The 4th lwarx parm (MUTEX_HINT_ACQ) is a cache
> > line optimization.
> >
> > But the important part is replacing the atomic_increment macro, which
> > does not include any memory barrier, with a explicit atomic add with a
> > leading release (___lll_rel_instr) barrier.
> >
> > With this patch pthread_once implements the required acquire / release
> > semantics.
> Right, but wouldn't a call to atomic_read_barrier followed by
> atomic_increment achieve the same result?
true.