This is the mail archive of the
mailing list for the glibc project.
Re: gcc 4.1 implements compiler builtins for atomic ops
- From: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- To: Anuj Goyal <anuj dot goyal at gmail dot com>
- Cc: hollis at penguinppc dot org, libc-alpha at sources dot redhat dot com, roland at redhat dot com
- Date: Sun, 26 Jun 2005 16:36:53 +1000
- Subject: Re: gcc 4.1 implements compiler builtins for atomic ops
- References: <email@example.com> <firstname.lastname@example.org> <1119742835.5133.12.camel@gaston> <email@example.com>
On Sat, 2005-06-25 at 19:45 -0700, Anuj Goyal wrote:
> Hey Ben,
> the ref is on Page 45 (search for Richard Henderson)
> OpenSolaris has a glibc implementation similar to the one you mentionin your email. However, some programs won't want to dive into glibcfor 5 assembly instructions (for example to atomically increment aninteger).
> Most modern architectures can do an atomic add or atomic increment inless than 10 assembly instructions. For older architectures (parisc)which don't have comparable assembly instructions you would have tosomehow emulate this in gcc which would be bad --- for this onearchitecture I agree with you that the "atomic" instructions should beprovided by glibc.
> I like the gcc approach better for modern architectures because youhave fine grained control depending on which processor you want totarget. As you say, CPU bugs are a problem, but I haven't heard oftoo many CPU specific bugs around the atomic operations... it ispretty important for the hardware guys to get this right.
> Would the glibc group prefer atomic instructions to be implemented asa compiler intrinsic or as a glibc call?
> My company has c++ developers who aren't terribly interested inassembly coding for our thread safe reference counting implementationand it has been a sticky point for years.
> OpenSolaris has made easier for us with the "atomic" glibc callshttp://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 havingto handroll our own.
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
as you start using atomics as locks, and spinning around, you end up
with even more architectural issues, like possibly causing livelocks by
putting too much pressure on the reservation mecanism or such things.
That's why I really think we should not have this done at the compiler
level, but rather at a library level. If glibc is not suitable, then
pick bits & pieces of implementations here or there and make a separate
library, there have been talks about doing that a few times on lists.