Re: powerpc pthread_once bug fix

[Jeff Law <law at redhat dot com>]

On 08/30/2012 03:09 PM, Steven Munroe wrote:
> 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.
So with that established, assuming the other hunks of Alan's patch 
remain the same, why does the sequence of atomic_read_barrier; 
atomic_increment work while Alan's last hunk not work?

Where "work" == my builds complete without hanging.

Jeff