From owner-freebsd-threads@FreeBSD.ORG Fri Jul 19 05:55:48 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C27B2FC2 for ; Fri, 19 Jul 2013 05:55:48 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1CB1A4 for ; Fri, 19 Jul 2013 05:55:48 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r6J5tkNh020988; Fri, 19 Jul 2013 01:55:46 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.9]); Fri, 19 Jul 2013 01:55:47 -0400 (EDT) Date: Fri, 19 Jul 2013 01:55:46 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Joe Marcus Clarke Subject: Re: Mutexes and error checking In-Reply-To: Message-ID: References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Koop Mast , freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 05:55:48 -0000 On Thu, 18 Jul 2013, Daniel Eischen wrote: > On Thu, 18 Jul 2013, 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. > > I tried Solaris 10. For an already locked PTHREAD_MUTEX_NORMAL > mutex: Ugh! I misread the problem when I tried to recreate it and test it on Solaris, so forget that last email. 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. Test program was updated: http://people.freebsd.org/~deischen/mutex_test.c -- DE