This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] [PATCH] Remove custom pthread_once implementation on sh.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Mon, 08 Dec 2014 19:04:33 +0100
- Subject: Re: [RFC] [PATCH] Remove custom pthread_once implementation on sh.
- Authentication-results: sourceware.org; auth=none
- References: <1418061225 dot 25868 dot 102 dot camel at triegel dot csb> <20141208180113 dot GJ4574 at brightrain dot aerifal dot cx>
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.