Re: Subtle bug in LinuxThreads pthread_once().

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

On 15 Mar 2000, Andreas Jaeger wrote:

> The test linuxthreads/ex2 is broken - it's running for 10 minutes now
> and didn't terminate.

The reason is that the pthread_mutex_t type does not keep track of ownership.

Or, rather, only one variations of the mutex keep track of this: namely the
PTHREAD_MUTEX_RECURSIVE_NP and PTHREAD_MUTEX_ERRORCHECK_NP variants.

The default PTHREAD_MUTEX_FAST_NP is just a thin wrapper for the internal
fastlock, which doesn't track ownership.

Therefore, the error checks in pthread_cond_*wait() are not possible, in
the general case.

Fortunately, the Single UNIX Specification does *not* require the detection
of the programming error of the calling thread not holding the mutex.
The only *required* error status is ETIMEDOUT; the others are listed
under a ``may'' clause. 

See:

http://www.opengroup.org/onlinepubs/007908799/xsh/pthread_cond_timedwait.html

My suggestion is to keep the checks, but make them like this:

    if (mutex->__m_kind != PTHREAD_MUTEX_FAST_NP && mutex->__m_owner != self)
	return EINVAL;

Still, this is adding overhead when the default fast mutexes are being used.
There is no benefit to portable code which stays away from the *_NP mutex
attributes---however, some people out there are using the error-checking
mutexes for debugging, and this would be helpful to them.