Re: powerpc pthread_once bug fix

[Alan Modra <amodra at gmail dot com>]

On Thu, Aug 30, 2012 at 03:46:07PM -0600, Jeff Law wrote:
> 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.

I wrote this code in the first instance using atomic_read_barrier
followed by atomic_increment..  The reason why I implemented the patch
as I did, is that the asm allows MUTEX_HINT_REL on lwarx.  Otherwise
the asm is identical to atomic_read_barrier followed by
atomic_increment.  Please look at the generated object code to verify
this is so (or to refute my claim and hopefully find why things are
going wrong).  Is UP defined for your builds?

-- 
Alan Modra
Australia Development Lab, IBM