This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update on freeze status of glibc 2.18?
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Roland McGrath <roland at hack dot frob dot com>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Ryan Arnold <rsa at us dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Fri, 21 Jun 2013 02:51:08 +0200
- Subject: Re: Update on freeze status of glibc 2.18?
- References: <20130610231903 dot D9C602C09B at topped-with-meat dot com> <51B66222 dot 1040300 at redhat dot com> <20130614224427 dot 4B2532C077 at topped-with-meat dot com> <51BF3CF8 dot 1010901 at redhat dot com> <1371494971 dot 16968 dot 21574 dot camel at triegel dot csb> <20130617193649 dot 7B5872C08D at topped-with-meat dot com> <1371503900 dot 16968 dot 21902 dot camel at triegel dot csb> <20130619224234 dot 5AC132C10E at topped-with-meat dot com> <1371733830 dot 964 dot 1089 dot camel at triegel dot csb> <20130620230930 dot 6F21E2C135 at topped-with-meat dot com> <20130621002109 dot GG6123 at two dot firstfloor dot org>
On Fri, 2013-06-21 at 02:21 +0200, Andi Kleen wrote:
> I appreciate all your efforts in designing this new ABI,
> but I don't think it's necessary.
>
> > That certainly seems very reasonable. Do you have a quick summary (or
> > pointer to something) of how the C++11 mutex semantics differ from the
> > POSIX mandate for PTHREAD_MUTEX_NORMAL?
>
> AFAIK it doesn't have the deadlock specification bug.
>
> I don't think it makes sense to back them with pthread mutexes at all --
> even though that is currently done. The pthread mutexes have a lot
> of fast path overhead for checking types etc. that C++ mutexes
> could in principle avoid. So a high performance implementation would
> not be based on the pthread code.
I agree about the fast path overhead. But glibc could offer streamlined
fast paths too for specific mutex types. And the non-C++11 pthreads
programs could make use of this mutex type too to get the most benefits
from the current elision implementation.
Another reason to keep the implementation in glibc would be to not
duplicate lots of pthreads locking code in libstdc++. For example,
things like any (future) spinning policies, systemtap probes, any
elision implementation and tuning policies, etc.