Update on freeze status of glibc 2.18?

[Torvald Riegel]

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.