Re: [RFC] [PATCH] Remove custom pthread_once implementation on sh.

[Rich Felker <dalias at libc dot org>]

On Mon, Dec 08, 2014 at 07:04:33PM +0100, Torvald Riegel wrote:
> On Mon, 2014-12-08 at 13:01 -0500, Rich Felker wrote:
> > On Mon, Dec 08, 2014 at 06:53:45PM +0100, Torvald Riegel wrote:
> > > This patch removes the custom implementation of pthread_once on sh.  I
> > > have not tested this, but the generic implementation in
> > > nptl/pthread_once.c works well on several architectures.
> > > 
> > > I don't claim to really understand sh assembly, but given that sh
> > > defines no HW barriers it seems that the pthread_once fast path would
> > > just be a normal load and a compiler barrier, which should be as fast in
> > > C as in assembler.
> > > 
> > > Removing the custom implementation will ease maintenance.  If we decide
> > > not to, I'd at least like to document why in the source of the custom
> > > custom implementation.
> > > 
> > > Thoughts?  OK to commit?
> > 
> > sh4a does have a hardware barrier, the "synco" instruction. Prior sh
> > models have no hardware atomics at all and use the kernel's "gusa"
> > atomic system that only works on non-smp. I'm not sure which of these
> > glibc supports, but if you support smp you presumably need "synco".
> 
> Thanks for the background.  I'll clarify what I wrote:
> glibc's implementation of atomic operations on sh defines no HW
> barriers.  It does use gusa it seems.

Yes, the code in lowlevel-atomic.h is using gusa. So it seems like
glibc does not support SMP on sh (only possible to support on sh4a+)
and as long as that's the case I agree there's no need for a hardware
barrier.

Rich