Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Jul 2013 01:55:46 -0400 (EDT)
From:      Daniel Eischen <deischen@freebsd.org>
To:        Joe Marcus Clarke <marcus@marcuscom.com>
Cc:        Koop Mast <kwm@rainbow-runner.nl>, freebsd-threads@freebsd.org
Subject:   Re: Mutexes and error checking
Message-ID:  <Pine.GSO.4.64.1307190152440.25756@sea.ntplx.net>
In-Reply-To: <Pine.GSO.4.64.1307182144030.23634@sea.ntplx.net>
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>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1307190152440.25756>