This is the mail archive of the libc-alpha@sourceware.org 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: [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.


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