[m-rev.] For review: Workaround Linux NTPL TSX bug (Mercury Bug: 334)
novalazy at gmail.com
Fri Jun 27 17:16:09 AEST 2014
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.
> > 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
PTHREAD_MUTEX_NORMAL for unreleased versions
More information about the reviews