From owner-freebsd-threads@FreeBSD.ORG  Sun Jul 21 20:52:14 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 DF00C815;
 Sun, 21 Jul 2013 20:52:14 +0000 (UTC)
 (envelope-from marcus@marcuscom.com)
Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209])
 by mx1.freebsd.org (Postfix) with ESMTP id A0E55231;
 Sun, 21 Jul 2013 20:52:14 +0000 (UTC)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1])
 by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6LKqCin001728;
 Sun, 21 Jul 2013 16:52:12 -0400 (EDT)
Received: from rtp-jclarke-8916.cisco.com (rtp-jclarke-8916.cisco.com
 [10.117.46.167])
 by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6LKq9VB024556;
 Sun, 21 Jul 2013 16:52:09 -0400 (EDT)
Message-ID: <51EC49F8.6070207@marcuscom.com>
Date: Sun, 21 Jul 2013 16:52:08 -0400
From: Joe Marcus Clarke <marcus@marcuscom.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Andriy Gapon <avg@FreeBSD.org>
Subject: Re: Mutexes and error checking
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> <20130721160220.GA38417@stack.nl>
 <51EC0BCF.6080501@FreeBSD.org>
In-Reply-To: <51EC0BCF.6080501@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 20:52:14 -0000

On 7/21/13 12:26 PM, Andriy Gapon wrote:
> on 21/07/2013 19:02 Jilles Tjoelker said the following:
>> So I think allowing pthread_mutex_unlock() by a different thread would
>> be a step backwards.
> 
> There is something else that bothers me too.
> Properly written code always "knows" whether it has a lock or not.  It does not
> try to unlock on a whim.  Apparently the software in question is not properly
> written.  Nevertheless, it takes care to check return status of
> pthread_mutex_unlock().  And, to add insult to injury, it depends on OS-specific
> behavior in doing so.  That seems like "two wrongs make a right" thing.

The specifics are this.  There are some GNOME/GTK+/GLib apps that are
crashing now that GLib checks the return of pthread_mutex_unlock() in
g_mutex_unlock().  While we can workaround this in GLib by simply
nop'ing the EPERM return, we'd like to pursue something that may be a
bit more manageable for those apps written for Linux that do not use GLib.

Again, I'm not arguing the voracity of the 3rd party app code, just the
discrepancy between Linux and Solaris compared to FreeBSD.

Joe

-- 
PGP Key : http://www.marcuscom.com/pgp.asc