Mutexes and error checking

[Joe Marcus Clarke]

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