This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]