Re: Question on when __pthread_lock second parameter shoudl be NULL

[Juergen Kreileder <jk at blackdown dot de>]

>>>>> "Kaz" == Kaz Kylheku <kaz@ashi.footprints.net> writes:

    Kaz> On Wed, 9 Aug 2000, Kevin B. Hendricks wrote:

    >> The JDK is returning with an error that indicates that the
    >> mutex is not being held by the same thread as the caller of
    >> pthread_condvar_timedwait.  This should not be happening and
    >> does not happen using ERRORCHECK mutexes.

    Kaz> You are suffering from a bug that is fixed in the main
    Kaz> trunk. See this ChangeLog entry:

    Kaz> 2000-04-16  Ulrich Drepper  <drepper@redhat.com>

    Kaz>         * condvar.c (pthread_cond_timedwait_relative): Don't
    Kaz>           test for owner if fast mutex is used. 

[...]

    Kaz> The problem is that the mutex ownership is being tested for
    Kaz> all mutex types, even ones that do not record the ownership!

That is true for the main trunk and was true for glibc-2.1.3 but now
the glibc-2-1-branch records ownership for fast mutexes.  What was the
reason for that change?

Here's a fix for the problem we see:

RCS file: /cvs/glibc/libc/linuxthreads/mutex.c,v
retrieving revision 1.9.2.4
diff -u -r1.9.2.4 mutex.c
--- mutex.c     2000/07/31 15:31:21     1.9.2.4
+++ mutex.c     2000/08/09 21:43:57
@@ -109,8 +109,8 @@
 {
   switch (mutex->__m_kind) {
   case PTHREAD_MUTEX_FAST_NP:
-    __pthread_unlock(&mutex->__m_lock);
     mutex->__m_owner = NULL;
+    __pthread_unlock(&mutex->__m_lock);
     return 0;
   case PTHREAD_MUTEX_RECURSIVE_NP:
     if (mutex->__m_count > 0) {



        Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux.html
JVM'01: http://www.usenix.org/events/jvm01/