From owner-freebsd-threads@FreeBSD.ORG Sun Jul 21 04:08:48 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 D97AFE31; Sun, 21 Jul 2013 04:08:48 +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 92B2214D; Sun, 21 Jul 2013 04:08:48 +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 r6L48fDi000644; Sun, 21 Jul 2013 00:08:41 -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 r6L48aak008654; Sun, 21 Jul 2013 00:08:37 -0400 (EDT) Message-ID: <51EB5EC4.6050802@marcuscom.com> Date: Sun, 21 Jul 2013 00:08:36 -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: Daniel Eischen Subject: Re: Mutexes and error checking References: <51E71D4F.5030502@marcuscom.com> <51E8061B.60906@marcuscom.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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: Sun, 21 Jul 2013 04:08:49 -0000 On 7/19/13 1:55 AM, Daniel Eischen wrote: > 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. Given that, should we do the same? Joe > > Test program was updated: > > http://people.freebsd.org/~deischen/mutex_test.c > -- PGP Key : http://www.marcuscom.com/pgp.asc