This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: gcc 4.1 implements compiler builtins for atomic ops
On Sun, 2005-06-26 at 21:23 +0200, Jakub Jelinek wrote:
> On Sun, Jun 26, 2005 at 11:53:43AM -0400, Daniel Jacobowitz wrote:
> > On Sun, Jun 26, 2005 at 04:36:53PM +1000, Benjamin Herrenschmidt wrote:
> > > Well, we have _at_least_ 40x which needs a sync in there, and you really
> > > don't want a sync on other processors for performance reasons. As soon
> >
> > GCC already supports atomic operations on many platforms. GCC will
> > support the 405CR erratum, next week or so. David's been working on
> > it.
> >
> > Let's face it - enough people dislike the overhead of a function call
> > for this that if glibc implemented them, they'd be inline functions,
> > and you'd have all the same problems.
>
> Well, glibc implements them already, though not in an installed header.
> See <atomic.h> and arch specific <bits/atomic.h> it uses.
Yes, I think glibc should expose them. And I also think they should NOT
be inline for the reasons I exposed, I really want the ability to
replace the implementation based on the CPU, firmware environment,
etc... without having to rebuild all applications. There are too many
subtle "issues" related to things like processor revision to let atomics
be directly inline in normal userland code.
I think this is a BAD idea. What should happen is for glibc and not gcc
to expose some sane atomic interfaces (and non inline).
Ben.