Date: Sun, 21 Jul 2013 12:48:14 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Andriy Gapon <avg@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: <Pine.GSO.4.64.1307211237440.6555@sea.ntplx.net> In-Reply-To: <51EC0BCF.6080501@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> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
--
DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1307211237440.6555>