[m-rev.] For review: Workaround Linux NTPL TSX bug (Mercury Bug: 334)

Paul Bone paul at bone.id.au
Fri Jun 27 16:18:26 AEST 2014


On Fri, Jun 27, 2014 at 03:33:46PM +1000, Peter Wang wrote:
> On Fri, 27 Jun 2014 11:27:40 +1000, Paul Bone <paul at bone.id.au> wrote:
> > 
> > Of course my change here is only a workaround.  The real fix is patching
> > glibc.
> 
> Well, I prefer you do not commit it.  If it's just to continue your
> development, I think you could rebuild glibc with --disable-lock-elision
> and LD_PRELOAD libpthread?

What if other users have the same error?  This affects all
asm_fast.gc.par.stseg grades.  I can't resonably ask other users, including
yourself, either to buy a processor without this extension or to always use
an older version of glibc.

> Otherwise, from what I can tell, calling pthread_mutexattr_settype with
> PTHREAD_MUTEX_DEFAULT (or maybe PTHREAD_MUTEX_NORMAL) is enough to
> disable lock elision, which is the same type of mutex as for
> PTHREAD_MUTEX_INITIALIZER.  You don't need to test the glibc version.

Are you saying that PTHREAD_MUTEX_DEFAULT and/or PTHREAD_MUTEX_NORMAL also
disable elision?

I test the glibc version incase the error checking with the attribute I have
chosen slows down use of the lock slightly (although I doubt it would be
noticable).


-- 
Paul Bone



More information about the reviews mailing list