Mutexes and error checking

[Konstantin Belousov]

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 http://sourceware.org/glibc/wiki/LockElisionGuide, 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20130721/ca1c4cc8/attachment.sig>