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] |
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. pthread_mutex_unlock() checks that a) mutex is owned by calling thread and 2) the status of the mutex when anded with 1 is non-zero (i.e. something is waiting). However, if alt_lock() had placed an address in this status field and not a 1 then the check will fail and EPERM returned. I believe the routine should look like:
--- mutex.c 2000/09/20 14:33:57 1.1
+++ mutex.c 2000/09/20 14:48:01
@@ -169,11 +169,11 @@
}
mutex->__m_owner = NULL;
__pthread_unlock(&mutex->__m_lock);
return 0;
case PTHREAD_MUTEX_ERRORCHECK_NP:
- if (mutex->__m_owner != thread_self() || (mutex->__m_lock.__status & 1) == 0)
+ if (mutex->__m_owner != thread_self() || mutex->__m_lock.__status == 0)
return EPERM;
mutex->__m_owner = NULL;
__pthread_alt_unlock(&mutex->__m_lock);
return 0;
case PTHREAD_MUTEX_TIMED_NP:
The programs that were crapping out are now working fine.
Comments?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |