gcc 4.1 implements compiler builtins for atomic ops
Carlos O'Donell
carlos@systemhalted.org
Mon Jun 27 17:10:00 GMT 2005
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
versionable interface.
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.
c.
More information about the Libc-alpha
mailing list