Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Jul 2013 21:29:01 +0300
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Daniel Eischen <deischen@FreeBSD.org>
Cc:        Joe Marcus Clarke <marcus@marcuscom.com>, Koop Mast <kwm@rainbow-runner.nl>, freebsd-threads@FreeBSD.org
Subject:   Re: Mutexes and error checking
Message-ID:  <51EC286D.4080208@FreeBSD.org>
In-Reply-To: <Pine.GSO.4.64.1307211237440.6555@sea.ntplx.net>
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> <Pine.GSO.4.64.1307182144030.23634@sea.ntplx.net> <Pine.GSO.4.64.1307190152440.25756@sea.ntplx.net> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> <51EC0BCF.6080501@FreeBSD.org> <Pine.GSO.4.64.1307211237440.6555@sea.ntplx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
on 21/07/2013 19:48 Daniel Eischen said the following:
> On Sun, 21 Jul 2013, Andriy Gapon wrote:
> 
>> on 21/07/2013 19:02 Jilles Tjoelker said the following:
>>> So I think allowing pthread_mutex_unlock() by a different thread would
>>> be a step backwards.
>>
>> There is something else that bothers me too.
>> Properly written code always "knows" whether it has a lock or not.  It does not
>> try to unlock on a whim.  Apparently the software in question is not properly
>> written.  Nevertheless, it takes care to check return status of
>> pthread_mutex_unlock().  And, to add insult to injury, it depends on OS-specific
>> behavior in doing so.  That seems like "two wrongs make a right" thing.
>>
>> I understand that "life is such", etc, but it hurts to see us bend for such a
>> backwards code.
> 
> I agree that this seems like broken software (threads releasing
> locks they don't own), but _if_ PTHREAD_MUTEX_NORMAL was
> explicitly set by the software, it could mean two things:
> 
>   o Assumption that PTHREAD_MUTEX_NORMAL mutexes are
>     inherently faster than PTHREAD_MUTEX_DEFAULT, or
> 
>   o The behavior of this type of mutex, at least in
>     regard to the unlock, is desired.
> 
> For the latter case, I'm thinking specifically of thread-safe
> libraries.  Maybe they don't care (in these unlock cases) because
> they know at the time that whatever the mutexes are protecting
> is stable.  They could use robust mutexes, but they may not
> be as widely implemented.
> 
> I think most folks assume that PTHREAD_MUTEX_NORMAL are
> the faster of the POSIX specified mutex types, but POSIX
> makes no such guarantee.  I think perhaps they need a
> PTHREAD_MUTEX_FAST or to just specify that it is the
> implementations fastest type of POSIX mutex.

Well, my opinion is that either you want error checking or not.
In the former case you use robust mutex and do other kinds of checks (like
return code of pthread_* functions), in the latter case you use normal mutex,
but then you don't do any return code checking.
Mixing the two approaches and expecting something sane is... insane :-)
JIMHO, of course.

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51EC286D.4080208>