Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Jul 2013 14:52:34 -0400
From:      Joe Marcus Clarke <marcus@marcuscom.com>
To:        Julian Elischer <julian@freebsd.org>
Cc:        Daniel Eischen <deischen@freebsd.org>, Koop Mast <kwm@rainbow-runner.nl>, freebsd-threads@freebsd.org
Subject:   Re: Mutexes and error checking
Message-ID:  <51E83972.9070902@marcuscom.com>
In-Reply-To: <51E80FF3.2080101@freebsd.org>
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> <51E80FF3.2080101@freebsd.org>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On 7/18/13 11:55 AM, Julian Elischer wrote:
> 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.

I think this would be as much/more work than trying to fix the problem
in the software or adding band-aids to abstraction packages like GLib.
If the consensus is we don't want to modify FreeBSD behavior, then we
will hack GLib and fix things tactically as we see them.

Joe

> 
> 
> 


-- 
PGP Key : http://www.marcuscom.com/pgp.asc



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?51E83972.9070902>