Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Jul 2013 19:39:37 +0300
From:      Konstantin Belousov <>
To:        Jilles Tjoelker <>
Cc:        Joe Marcus Clarke <>, Daniel Eischen <>,, Koop Mast <>
Subject:   Re: Mutexes and error checking
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 21, 2013 at 06:02:20PM +0200, Jilles Tjoelker wrote:
> On Sun, Jul 21, 2013 at 12:08:36AM -0400, Joe Marcus Clarke wrote:
> > On 7/19/13 1:55 AM, Daniel Eischen wrote:
> > > It seems Solaris behaves like Linux with PTHREAD_MUTEX_NORMAL
> > > and _unlocking_ mutexes owned by other threads (dead or not).
> > > Solaris only returns EPERM for PTHREAD_MUTEX_ERRORCHECK
> > > mutexes.
> > Given that, should we do the same?
> According to, it seems
> like glibc wants to change behaviour here. If a mutex is implemented via
> some sort of transactional memory, it may not work correctly if the
> mutex is used as a semaphore with a different thread unlocking it. In
> particular, attempting to commit a transaction via the XEND instruction
> will cause a general protection fault if no transaction is in progress.
> Adding software checks against these conditions will use up valuable
> transactional memory tracking space.
For the XEND, Intel advises to use XTEST before to distinguish between
transactional and not transactional executions.

The elided unlock routine has to test the value of lock anyway,
to distinguish between elided and fallback locking.  Then, it is not
too hard to add a check for the case 'locked, but not by us', since
we have to check to avoid XEND for non-elided locks already.

> So I think allowing pthread_mutex_unlock() by a different thread would
> be a step backwards.
But this is true regardless of the TSX.

Content-Type: application/pgp-signature

Version: GnuPG v2.0.20 (FreeBSD)



Want to link to this message? Use this URL: <>