Mutexes and error checking

[Julian Elischer]

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.