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
- From: Carlos O'Donell <carlos at systemhalted dot org>
- To: Anuj Goyal <anuj dot goyal at gmail dot com>
- Cc: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>,hollis at penguinppc dot org, libc-alpha at sources dot redhat dot com,roland at redhat dot com
- Date: Sun, 26 Jun 2005 17:29:29 -0400
- Subject: Re: gcc 4.1 implements compiler builtins for atomic ops
- References: <2f225d01050625091875932e04@mail.gmail.com> <7a02832e219e2e6ceca78f06264d7a94@penguinppc.org> <1119742835.5133.12.camel@gaston> <2f225d0105062519451d9e9c85@mail.gmail.com>
On Sat, Jun 25, 2005 at 07:45:51PM -0700, Anuj Goyal wrote:
> 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.
We will be working to implement the atomic ops in gcc on parisc.
For parisc the atomic operation is implemented as a light-weight
syscall, on the gateway page, consisting of 18 instructions on the fast
path. Tests show this is as close to optimal as possible. With scaling
out to ~16 cpus (all on paper though). I could probably re-architect the
light-weight-syscall locking to scale to higher cpus.
This has the unfortunate issue of requiring a newer kernel. I'm not sure
how to handle this type of requirement against gcc. With glibc I could
use a vDSO or --enable-kernel and some package management entries.
The implementation of atomic ops in glibc is exactly the same, just
wrapped around a function call.
Cheers,
Carlos.