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:41:04 -0700 (PDT)
- cc: libc-alpha at sources dot redhat dot com
On Wed, 20 Sep 2000 Neale.Ferguson@SoftwareAG-USA.com wrote:
> Does that mean my fix is not usable and my analysis flawed (not atypical I'm
> afraid ;-))? If so, where did I go wrong?
The patch breaks correct behavior. I think where you went wrong was by wrongly
applying knowledge of the fastlock internals to the alternate lock which is
different.
> I've also noted in pthread_mutex_unlock() for mutex kinds of
> PTHREAD_MUTEX_RECURSIVE_NP that if a mutex has been unlocked such that the
> count is 0 then _pthread_unlock() is called. If a routine were to call
> pthread_mutex_unlock() again with the same mutex then _pthread_unlock() is
> called again which causes grief. Shouldn't there be a test like...
>
> if (mutex->__m_owner != NULL) {
> mutex->__m_owner = NULL;
> __pthread_unlock(&mutex->__m_lock);
> return 0;
> }
> else
> return EPERM;
No. According to the applicable standards, this error check is permitted, but
not required. The behavior is simply undefined. The rationale is that the
check is a waste of time in provably correct programs, which can just ignore
the return value of these operations because it is always zero. Except in the
case of PTHREAD_MUTEX_ERRORCHECK, implementors have a choice whether or not to
implement the checks.
Unfortunately, there is currently no PTHREAD_MUTEX_ERRORCHECK_RECURSIVE_NP for
people who are looking for recursive behavior as well as error checking.
It may be wortwhile to create this.