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]
Other format: [Raw text]

Re: [libc-alpha] Re:linuxthreads bug in 2.2.4 under ppc linux


On Fri, 7 Dec 2001, Kevin B. Hendricks wrote:

> Date: Fri, 7 Dec 2001 23:11:55 -0500
> From: Kevin B. Hendricks <kevin.hendricks@sympatico.ca>
> To: libc-alpha@sources.redhat.com
> Cc: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>,
>      Franz Sirl <Franz.Sirl-ppc@lauterbach.com>
> Subject: [libc-alpha] Re:linuxthreads bug in 2.2.4 under ppc linux
> 
> Hi,
> 
> Looking at __pthread_alt_lock()
> 
> Why don't we eve initialize the wait_node.thr field to anything at all 
> (not even NULL) if the oldstatus was zero?  This seems a bit dangerous to 
> leave in an unitialized state.  Shouldn't it be set to 0?

I don't think there is any danger. There is no reason not to set this to
zero. If doing so will prevents someone from wasting time wondering
whether there is a reason it's not initialized, then it's worthwhile
to me.

> Also are there any known issues with thread_self() to incorrectly 
> returning 0 if a thread was just recently started?

Not known to me.

The one known issue with these locks (which I have not fixed yet) is
that the recycling of the wait nodes in the global queue is broken.
(See wait_node_alloc and wait_node_free).  But that only happens for
dynamically allocated wait nodes, which are only created if you use the
locking function with a timeout, __pthread_alt_timedlock,
which is currently only used by pthread_mutex_timedlock. If you are not
generating calls to __pthread_alt_timedlock, this issue should not be
the cause of the failure you are seeing.

I should get on top of this ASAP.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]