This is the mail archive of the
mailing list for the glibc project.
Re: gcc 4.1 implements compiler builtins for atomic ops
- From: Anuj Goyal <anuj dot goyal at gmail dot com>
- To: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>, hollis at penguinppc dot org
- Cc: libc-alpha at sources dot redhat dot com, roland at redhat dot com
- Date: Sat, 25 Jun 2005 19:45:51 -0700
- Subject: Re: gcc 4.1 implements compiler builtins for atomic ops
- References: <email@example.com> <firstname.lastname@example.org> <1119742835.5133.12.camel@gaston>
- Reply-to: Anuj Goyal <anuj dot goyal at gmail dot com>
the ref is on Page 45 (search for Richard Henderson)
OpenSolaris has a glibc implementation similar to the one you mention
in your email. However, some programs won't want to dive into glibc
for 5 assembly instructions (for example to atomically increment an
Most modern architectures can do an atomic add or atomic increment in
less than 10 assembly instructions. For older architectures (parisc)
which don't have comparable assembly instructions you would have to
somehow emulate this in gcc which would be bad --- for this one
architecture I agree with you that the "atomic" instructions should be
provided by glibc.
I like the gcc approach better for modern architectures because you
have fine grained control depending on which processor you want to
target. As you say, CPU bugs are a problem, but I haven't heard of
too many CPU specific bugs around the atomic operations... it is
pretty important for the hardware guys to get this right.
Would the glibc group prefer atomic instructions to be implemented as
a compiler intrinsic or as a glibc call?
My company has c++ developers who aren't terribly interested in
assembly coding for our thread safe reference counting implementation
and it has been a sticky point for years.
OpenSolaris has made easier for us with the "atomic" glibc calls
atomic_add_16(3C) – atomic operations
atomic_add_16_nv(3C) – atomic operations
atomic_add_32(3C) – atomic operations
atomic_add_32_nv(3C) – atomic operations
atomic_add_64(3C) – atomic operations
atomic_add_64_nv(3C) – atomic operations
atomic_add_long(3C) – atomic operations
atomic_add_long_nv(3C) – atomic operations
atomic_and_32(3C) – atomic operations
atomic_and_uint(3C) – atomic operations
atomic_ops(3C) – atomic operations
so for Solaris 10 on x86 we can just make these calls without having
to handroll our own.
On 6/25/05, Benjamin Herrenschmidt <email@example.com> wrote:
> On Sat, 2005-06-25 at 12:27 -0500, Hollis Blanchard wrote:
> > On Jun 25, 2005, at 11:18 AM, Anuj Goyal wrote:
> > > I remember having a conversation recently with one of u (sorry can't
> > > remember who) about gcc and the atomic operations for different
> > > architectures. Remember I was the annoying developer trying to
> > > figure out the asm syntax for gcc on ppc? :)
> > >
> > > http://www.gccsummit.org/2005/2005-GCC-Summit-Proceedings.pdf
> > >
> > > page 45.
> > >
> > > looks like gcc will have atomic intrinsics for these operations.
> > Good to know. Thanks for the mail...
> I didn't see anything releavant to atomics in that paper, what page
> precisely ?
> Probably not that a good idea anyway. I'd rather isolate these into
> glibc (and vDSO) because of various funky things, like some CPUs revs
> needing specific workarounds. Very difficult to get that right at the
> compiler level and would require a rebuild of applications for now CPUs,
> bad ideas. Also, for things like SMT, the ability to have atomic-based
> locks use proper calls to avoid "hot" spinning in a thread is not
> something you want to hard code in an application.