From owner-freebsd-threads@FreeBSD.ORG Thu Jul 18 18:52:36 2013 Return-Path: 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 D2F69DE for ; Thu, 18 Jul 2013 18:52:36 +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 8A96EFE1 for ; Thu, 18 Jul 2013 18:52:36 +0000 (UTC) X-TACSUNS: Virus Scanned Received: from chook.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 r6IIqYDo012052 for ; Thu, 18 Jul 2013 14:52:34 -0400 (EDT) Received: from dhcp-10-150-54-149.cisco.com (dhcp-10-150-54-149.cisco.com [10.150.54.149]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6IIqYjc007543; Thu, 18 Jul 2013 14:52:34 -0400 (EDT) Message-ID: <51E83972.9070902@marcuscom.com> Date: Thu, 18 Jul 2013 14:52:34 -0400 From: Joe Marcus Clarke 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: Julian Elischer Subject: Re: Mutexes and error checking References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> <51E80FF3.2080101@freebsd.org> In-Reply-To: <51E80FF3.2080101@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Koop Mast , freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 18:52:37 -0000 On 7/18/13 11:55 AM, Julian Elischer wrote: > On 7/18/13 11:22 PM, Daniel Eischen wrote: >> On Thu, 18 Jul 2013, Joe Marcus Clarke wrote: >> >>> On 7/18/13 11:09 AM, Daniel Eischen wrote: >>>> On Wed, 17 Jul 2013, Joe Marcus Clarke wrote: >>>> >>>>> It seems we might have a discrepancy between the way our pthread >>>>> implementation works compared to Linux. If a mutex is set to NORMAL >>>>> type and one goes to unlock it, EPERM is returned unless the current >>>>> thread is the mutex owner. While this sounds perfectly sane, it >>>>> appears >>>>> Linux only returns EPERM if the mutex type is ERRORCHECK. >>>>> >>>>> We are seeing some problems in ported code because of this. As a >>>>> suggestion, if people agree, would it be possible to emulate the >>>>> behavior of Linux and only return EPERM if the mutex is of type >>>>> ERRORCHECK or RECURSVIE? >>>> >>>> First, any software that does that is broken. >>>> >>>> Second, the POSIX spec seems to imply that an error is returned >>>> when a different thread tries to unlock an already locked mutex: >>>> >>>> >>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.htm >>>> >>>> >>>> >>>> Is the mutex robust or not robust? If not robust >>>> (PTHREAD_MUTEX_STALLED), then a PTHREAD_MUTEX_NORMAL mutex >>>> cannot be unlocked by any other thread than the owner. >>>> So, it would seem to be wrong to _not_ return an >>>> error when the mutex is not unlocked after >>>> pthread_mutex_unlock() returns. >>>> >>> >>> Don't get me wrong, I agree with you. This behavior should result in >>> EPERM. However, my comment was more on the portability side to maintain >>> parity with Linux in order to support the 3rd party code people wanting >>> to run on FreeBSD. We can workaround it in some cases, but I was >>> floating up to you guys to perhaps create a broader workaround. >> >> If it is not a robust mutex, the behavior _is_ undefined, so I >> think Linux is allowed to return 0 (no error), just as FreeBSD >> is allowed to return an error. I will check Solaris 10 later >> to see what it does. >> >> How many cases of this are we seeing in ports? How hard is >> it to upstream portability fixes to them - are they usually >> willing to accept these types of fixes? > > I think the answer would be to declare a new type of mutex that allows > this ant document it as to only be used in broken linux code. don't > know how much work it would be however. I think this would be as much/more work than trying to fix the problem in the software or adding band-aids to abstraction packages like GLib. If the consensus is we don't want to modify FreeBSD behavior, then we will hack GLib and fix things tactically as we see them. Joe > > > -- PGP Key : http://www.marcuscom.com/pgp.asc