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

[Paul Bone]

On Fri, Jun 27, 2014 at 05:16:09PM +1000, Peter Wang wrote:
> On Fri, 27 Jun 2014 16:18:26 +1000, Paul Bone <paul at bone.id.au> wrote:
> > 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.
> 
> I guess I'm expecting that it to be fixed one way or another, in due
> time, if more popular Boehm GC-using software is affected.

I've no intention of waiting the unspecified amount of time it will take for
    1) the bug to be acknowledged*
    2) the bug to be patched
    3) the patches to trickle down to actually be installed on people's
       systems.

  *: I don't think that the developers of glibc and/or Andi will actually be
     any worse than any other developer in this regard.  I'm not making a
     personal attack I'm just cynical.

> > > 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?
> 
> PTHREAD_MUTEX_DEFAULT for glibc-2.19
> http://repo.or.cz/w/glibc.git/commit/49186d21ef2d87986bccaf0a7c45c48c91b265f3
> PTHREAD_MUTEX_NORMAL for unreleased versions
> http://repo.or.cz/w/glibc.git/commit/673659263d956f45f1ce0c66900fa7f1129db74a

Okay, that's certainly simpler.  I'm happy to remove all the conditional
compilation and testing of glibc's version and always use
PTHREAD_MUTEX_NORMAL.

The man page for pthread_mutexattr_settype says that PTHREAD_MUTEX_NORMAL
locks will deadlock if you try and lock them a second time from the same
thread, which (AIUI) an elision implementation can't handle.  So this is
probably the most reliable incase in the future PTHREAD_MUTEX_DEFAULT is
ever assigned to some other behaviour.


-- 
Paul Bone