From owner-freebsd-threads@FreeBSD.ORG  Sun Jul 21 16:02:34 2013
Return-Path: <owner-freebsd-threads@FreeBSD.ORG>
Delivered-To: freebsd-threads@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by hub.freebsd.org (Postfix) with ESMTP id D67D4813;
 Sun, 21 Jul 2013 16:02:34 +0000 (UTC) (envelope-from jilles@stack.nl)
Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107])
 by mx1.freebsd.org (Postfix) with ESMTP id 9F9C1813;
 Sun, 21 Jul 2013 16:02:34 +0000 (UTC)
Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131])
 by mx1.stack.nl (Postfix) with ESMTP id 892361203C7;
 Sun, 21 Jul 2013 18:02:20 +0200 (CEST)
Received: by snail.stack.nl (Postfix, from userid 1677)
 id 60E5428494; Sun, 21 Jul 2013 18:02:20 +0200 (CEST)
Date: Sun, 21 Jul 2013 18:02:20 +0200
From: Jilles Tjoelker <jilles@stack.nl>
To: Joe Marcus Clarke <marcus@marcuscom.com>
Subject: Re: Mutexes and error checking
Message-ID: <20130721160220.GA38417@stack.nl>
References: <51E71D4F.5030502@marcuscom.com>
 <Pine.GSO.4.64.1307181059460.22570@sea.ntplx.net>
 <51E8061B.60906@marcuscom.com>
 <Pine.GSO.4.64.1307181118100.22570@sea.ntplx.net>
 <Pine.GSO.4.64.1307182144030.23634@sea.ntplx.net>
 <Pine.GSO.4.64.1307190152440.25756@sea.ntplx.net>
 <51EB5EC4.6050802@marcuscom.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <51EB5EC4.6050802@marcuscom.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Daniel Eischen <deischen@freebsd.org>, Koop Mast <kwm@rainbow-runner.nl>,
 freebsd-threads@freebsd.org
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-threads>, 
 <mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
 <mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jul 2013 16:02:34 -0000

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.

So I think allowing pthread_mutex_unlock() by a different thread would
be a step backwards.

-- 
Jilles Tjoelker