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: Rich Felker <dalias at libc dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Mon, 8 Dec 2014 13:01:13 -0500
- 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>
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".
Rich