This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Question on when __pthread_lock second parameter shoudl be NULL
- To: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Subject: Re: Question on when __pthread_lock second parameter shoudl be NULL
- From: Ulrich Drepper <drepper at redhat dot com>
- Date: 09 Aug 2000 21:34:33 -0700
- Cc: "Kevin B. Hendricks" <khendricks at ivey dot uwo dot ca>, kazi at ashi dot footprints dot net, libc-alpha at sources dot redhat dot com
- References: <Pine.LNX.4.10.10008091300400.18154-100000@ashi.FootPrints.net>
- Reply-To: drepper at cygnus dot com (Ulrich Drepper)
Kaz Kylheku <kaz@ashi.footprints.net> writes:
> > 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?
No no, look at the code. If we actually get the self pointer we pass
it down. In the case of PTHREAD_MUTEX_ADAPTIVE_NP we don't need self
in the mutex function and therefore pass NULL.
> 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?
I'll try adding this. But I'm not sure about the implications in the moment.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------