Date: Sun, 31 May 1998 15:09:57 +1000 (EST) From: John Birrell <jb@cimlogic.com.au> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: jb@cimlogic.com.au, current@FreeBSD.ORG Subject: Re: pthreads and thread-specific? Message-ID: <199805310509.PAA13433@cimlogic.com.au> In-Reply-To: <199805310254.TAA18874@rah.star-gate.com> from Amancio Hasty at "May 30, 98 07:54:35 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Amancio Hasty wrote:
> Hi John,
>
> It looks like the threads are waiting on a dead thread...
>
> I stuck this in uthread_info:
[...]
I don't think you needed the outer loop. Chuckle.
> for (itr = 0; itr < PTHREAD_DESTRUCTOR_ITERATIONS; itr++) {
[...]
>
> DEAD THREADS
>
> Thread 0x8050800 prio 64 [/usr/src/lib/libc_r/uthread/uthread_exit.c:176]
Hmmm, so Elvis really isn't dead. He's just deadlocked waiting on a
spinlock. 8-)
For the thread to be dead, it must have completed the cleanup. There is
only one place where it sets it's state to PS_DEAD and that is after all
exit processing has been completed and it has removed itself from the
list of active threads. As far as I can see, the _spinlock/_atomic_unlock
calls are correctly paired in src/lib/libc_r/uthread/uthread_spec.c,
so it looks like the _atomic_unlock call hasn't done it's job. Is the
_atomic_unlock linked into the process from libc_r, or has another
function of the same name been linked in first? You are linking with
gcc -pthread on a -current system, aren't you?
--
John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805310509.PAA13433>