Re: Question on when __pthread_lock second parameter shoudl be NULL

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

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

> Date: Wed, 09 Aug 2000 15:33:52 -0400
> From: Kevin B. Hendricks <khendricks@ivey.uwo.ca>
> To: kazi@ashi.footprints.net, libc-alpha@sources.redhat.com
> Subject: Question on when __pthread_lock second parameter shoudl be NULL
> 
> Hi Kaz,
> 
> Sorry to bother you but I am trying to tack down yet another bug with the cvs
> glibc-2.1 branch of glibc 2.1.3 and the jdk native threads. I hope you can
> answer a couple of questions:
> 
> 1. when should __pthread_lock (in spnlock.c) second parameter be NULL vs self?

When there is no efficiency advantage to be gained from eliminating redundant
calls to thread_self(). The __pthread_lock function should work correctly
either way, but it has to make a call to thread_self() if you don't give
it the self pointer.

> 2. why does the __pthread_message DEBUG function not work anymore (always get
> seg-fault in

Probably because the code has rotted due to disuse.

>   iovsprintf.c:line 47 when trying to access errno location).  This happens no
> matter how I play
>   with sprintf, vsprintf, etc

This smells like a glibc initialization issue: namely, trying to use the
thread-specific errno location before the thread library is initialized.

Under LinuxThreads, the errno location is in the thread descriptor of the
calling thread, which requires some setup even for the main thread.

I think that this problem could be trivially fixed by having a static
initializer for the errno-related fields of the main thread's descriptor.

Currently, these fields are set up in __pthread_initialize_minimal() and
so are null until that function is called.  All the function does is
assign the addresses of the statics _errno and _h_errno which can be done
statically.

> 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.

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

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

        * condvar.c (pthread_cond_timedwait_relative): Don't test for owner
        if fast mutex is used.  Don't initialize `already_canceled' twice.
        Correctly test for return value of timedsuspend.

        * pthread.c: Correct long-time braino.  We never set SA_SIGINFO and
        therefore don't need the _rt versions of the signal handlers.

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

> The only differnences in mutex.c that show up are in pthread_mutex_lock where
> __pthread_lock is called with NULL as the second parameter for the FAST_NP and
> with self for the ERRORCHECK mutexes and I was wondering why?

This is a performance bug. Because the pthread_mutex_lock() function acquires
the self pointer, it should pass it down to __pthread_lock so that
__pthread_lock doesn't have to make a redundant call to thread_self().

This issue still exists on the main trunk! Ulrich, can you commit a fix?

Also, can we change the initializer for the main thread descriptor so that
it directly initializes the p_errnop and p_h_errnop members with
&_errno and &_h_errno, respectively?