This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 03/11] Add external interface changes: new lock types for pthread_mutex_t
- From: Dominik Vogt <vogt at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Fri, 14 Jun 2013 10:44:52 +0200
- Subject: Re: [PATCH 03/11] Add external interface changes: new lock types for pthread_mutex_t
- References: <1370969416-8337-1-git-send-email-andi at firstfloor dot org> <1370969416-8337-4-git-send-email-andi at firstfloor dot org> <1371140842 dot 16968 dot 19094 dot camel at triegel dot csb> <20130613211520 dot GP6123 at two dot firstfloor dot org> <1371192753 dot 16968 dot 19724 dot camel at triegel dot csb>
- Reply-to: vogt at linux dot vnet dot ibm dot com
On Fri, Jun 14, 2013 at 08:52:33AM +0200, Torvald Riegel wrote:
> On Thu, 2013-06-13 at 23:15 +0200, Andi Kleen wrote:
> > I'm completely opposed to this. This would kill the major benefit
> > for even doing all of this in glibc.
>
> If you mean "the major benefit" in the sense of the only major benefit,
> then I disagree. It would be good to have it for existing binaries, but
> once they get recompiled, they will be able to benefit from lock
> elision.
Has anybody actually _seen_ these benefits with existing software?
I can sure make up artificial programs that benefit from elision,
but I have not yet seen a real (= existing) program that runs
noticably faster with lock elision in pthread mutexes and rwlocks.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany