Mutexes and error checking

[Daniel Eischen]

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