This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Patch to mutex.c


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]