Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Jul 2013 23:55:31 +0800
From:      Julian Elischer <>
To:        Daniel Eischen <>
Cc:        Joe Marcus Clarke <>, Koop Mast <>,
Subject:   Re: Mutexes and error checking
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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
>>> 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:
>>> Is the mutex robust or not robust?  If not robust
>>> 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.

Want to link to this message? Use this URL: <>