Re: gcc 4.1 implements compiler builtins for atomic ops

[Anuj Goyal <anuj dot goyal at gmail dot com>]

Hey Ben,

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
integer).

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
http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr0t?q=atomic_add16&a=expand

 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 <benh@kernel.crashing.org> 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.
> 
> Ben.
> 
> 
>