Mutexes and error checking

Daniel Eischen deischen at freebsd.org
Thu Jul 18 15:22:43 UTC 2013


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?

-- 
DE


More information about the freebsd-threads mailing list