Lock elision problems in glibc-2.18

[Andi Kleen]

Dominik Vogt <vogt@linux.vnet.ibm.com> writes:

> The current implementation of pthread_mutex lock elision is
> problematic if software uses a glibc with elision and other pieces
> of code that use transactions (other libraries for example).  The
> root cause of the problem is that transactions may be used in
> several independent contexts, but the cpu automatically nests
> these into the same transaction.

As I wrote we did that intentionally to make it possible to profile
lock busy.  Profiling is very important.

In general if lock is busy the transaction is unlikely to survive
anyways, as the chance of conflict on the lock variable is quite high.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only