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: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot jf dot intel dot com>
- Date: Fri, 14 Jun 2013 08:52:33 +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>
On Thu, 2013-06-13 at 23:15 +0200, Andi Kleen wrote:
> > Please give PTHREAD_MUTEX_DEFAULT a new enum value, leaving
> > PTHREAD_MUTEX_NORMAL unchanged. Next, don't use elision for
> > PTHREAD_MUTEX_NORMAL.
>
> This would mean no elision for existing binaries.
Yes, I'm aware of this. And that's an unfortunate situation to be in,
but I don't see another way to ensure that we still comply with the
POSIX requirements -- we can't just ignore those. Since we had the
discussion about the semantics months ago, I haven't seen someone else
suggest a different way to solve this.
> 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.
I think you should also consider the risk of deviating from the POSIX
semantics: If, for example, distributions do not enable elision because
they are worried about breaking existing programs, then this will lead
to elision being less widely used than if it weren't available just for
binaries that haven't been recompiled.
Torvald