This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Lock elision implementation guidelines
> I don't think this is any more difficult than saying "we made sqrt XX%
> slower to preserve the property that the result is correctly rounded".
More like "we made sqrt XX% slower to deliberately add a bug to it".
Deadlocks are bugs!
> > > > Note that POSIX pthreads does not export enough primitives for
> > > > efficient spinning. However that's good for lock elision.
> > >
> > > Can you elaborate? You can both do a trylock() and block, so it seems
> > > most of it is there in principal. There's no getlock() or something
> > > like that with which you could do test-and-test-and-set like locks, but
> > > OTOH perhaps you can get as similar effect with backoff.
> >
> > You normally need to spin reading, to prevent a flood of unnecessary
> > cache line conflicts. Even with backoffs that works much better.
>
> I'm not clear on how you'd cause a flood of cache line conflicts
> accessing nothing but your own thread's stack and possibly memory in
You're writing to the lock value itself, competing with other CPUs.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.