This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Patch to mutex.c
- To: Neale dot Ferguson at SoftwareAG-USA dot com
- Subject: Re: Patch to mutex.c
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Wed, 20 Sep 2000 09:03:22 -0700 (PDT)
- cc: libc-alpha at sources dot redhat dot com
On Wed, 20 Sep 2000 Neale.Ferguson@SoftwareAG-USA.com wrote:
> Date: Wed, 20 Sep 2000 10:55:12 -0400
> From: Neale.Ferguson@SoftwareAG-USA.com
> To: libc-alpha@sources.redhat.com
> Subject: Patch to mutex.c
>
> I have been encountering problems with pthread_mutex_unlock(). For cases
> where the mutex kind is PTHREAD_MUTEX_ERRORCHECK_NP, when a lock is called
> it uses __pthread_alt_lock() which results in either a 1 or a non-zero
> address being placed in the mutex status field depending if there are more
> than one waiters I assume.
What you are describing is the ``original fastlock'' which continues to be
used for the default mutex attribute.
In the ``alternate fastlock'', the status field is actually a bitfield. Only
the least significant bit indicates whether or not the lock is currently owned.
The other bits constitute a pointer to the head of the list of waiting threads,
which could be null. (The correct pointer is formed by masking away the locked
bit).
These two fields are independent. Any combination of states is possible, in
particular the case when threads are queued, but the lock is not locked.