This is the mail archive of the
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: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- Cc: Anuj Goyal <anuj dot goyal at gmail dot com>, hollis at penguinppc dot org,libc-alpha at sources dot redhat dot com, roland at redhat dot com,John David Anglin <dave dot anglin at nrc-cnrc dot gc dot ca>
- Date: Mon, 27 Jun 2005 13:09:55 -0400
- 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> <20050626212926.GC5269@systemhalted.org> <1119826233.5133.36.camel@gaston>
On Mon, Jun 27, 2005 at 08:50:33AM +1000, Benjamin Herrenschmidt wrote:
> > 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.
> So you are putting vDSO dependencies in gcc ? ugh ?
No. Just thinking out loud. GCC could just call the light weight syscall
itself, but this is a last resort.
> Am I the only one to think that this is a very bad idea ?
I support the idea of moving this out of the compiler and into glibc
and a vDSO.
> Damn, these things should be in glibc, not the compiler !
I want to use the vDSO to hide the light-weight-syscall behind a
If gcc required atomic operations they would come from glibc or the
vDSO. I am willing to pay the price of a function call. In gcc I will
just emit a libcall.
The C++ spec that will require atomic increment is going to have to make
concesions for architectures that support only mutex style locking
insns. I brought this up with Richard Henderson at GCC Summit.