This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc 4.1 implements compiler builtins for atomic ops


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]