[m-dev.] Lock Elision in eglibc 2.19

[Andi Kleen]

On Sat, Jun 21, 2014 at 11:14:13AM +1000, Paul Bone wrote:
> I noticed the following error:
> mercury_compile: ../nptl/pthread_mutex_lock.c:80: __pthread_mutex_cond_lock: Ass
> ertion `mutex->__data.__owner == 0' failed.
> 
> This is thrown (indirectly) from a call to pthread_cond_wait in
> pthread_support.c line 2036 in Boehm GC 7.4.2  I have the same problem with
> Boehm Gc 7.2.  There doesn't appear to be anything suspicious about the use
> of the mutex or condition variable involved here.

This could be a variant of 
https://sourceware.org/bugzilla/show_bug.cgi?id=16657

Do the patches there help?

> A different bug affecting libtirpc and mount_nfs also started occuring when
> I upgraded to eglibc 2.19.  When investigating this I found that eglibc 2.19

Likely related to locking?

> As a work-around I'd like to explicitly disable elision for this mutex.
> I've searched the glibc/eglibc sources and documentation and haven't found a
> way to disable elision.  But some things I read (mailing list messages etc)
> say that it should be possible either per mutex or completely (with an
> environment variable).  Could you tell me how?  Thanks.

My patches to do this were unfortunately not accepted. glibc
supports it internally but there is no way to request it 
for user programs. I hope this can be revisited in the future.

The old tuning patches are in my github tree in the rtm-devel9 branch.
http://github.com/andikleen/glibc

> I have a second question that is less important, but I'd like to understand
> nevertheless.  Your LWN article suggests that the entire critical section
> (from pthread_mutex_lock to pthread_mutex_unlock) is a transactional memory
> transaction.  Have I understood correctly?

Yes.

> If so, why not just start and
> finish the transactional memory transaction within the pthread_mutex_lock
> code?  That is, after acquiring the lock, finish the TM transaction so that
> the processor doesn't need to handle all the memory use until the
> pthread_mutex_unlock call specially.

The point of lock elision is to allow full parallelism of the critical
section including all memory accesses in it. So the transaction 
has to span the whole critical section, otherwise atomicity couldn't
be guaranteed.

Here's a newer article that has some more details:

http://queue.acm.org/detail.cfm?id=2579227

-Andi

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