This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Lock elision implementation guidelines
- From: Andi Kleen <ak at linux dot jf dot intel dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, andi <andi at firstfloor dot org>
- Date: Fri, 7 Jun 2013 09:29:12 -0700
- Subject: Re: [RFC] Lock elision implementation guidelines
- References: <1360527652 dot 3065 dot 11521 dot camel at triegel dot csb> <1370618459 dot 16968 dot 11300 dot camel at triegel dot csb>
On Fri, Jun 07, 2013 at 05:20:59PM +0200, Torvald Riegel wrote:
> I've put those guidelines up as a page on the wiki:
> http://sourceware.org/glibc/wiki/LockElisionGuide
>
> I incorporated the comments that came up in the discussion, and tried to
> represent the results of this discussion. Please speak up if there are
> points you disagree with.
I don't see much sense to write such a guide out of theoretical considerations.
Any practical guide needs to be based on experience.
Many aspects of lock elision can be non intuitive and need validation on
real systems.
Please play around with the implementation, test it with your favourite
applications and then write something up.
I only glimpsed over it, but:
- the trylock section discusses lots of stuff that is impractical/slow and
doesn't cover what has been actually implemented.
- it's useless to write up a "tuning roadmap" that is not resourced.
As this is free software only what someone works on will happen.
-Andi
--
ak@linux.intel.com -- Speaking for myself only