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]

Patch to mutex.c


Title: 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. 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]