Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 30 May 1998 22:21:00 -0700
From:      Amancio Hasty <hasty@rah.star-gate.com>
To:        John Birrell <jb@cimlogic.com.au>
Cc:        current@FreeBSD.ORG
Subject:   Re: pthreads and thread-specific? 
Message-ID:  <199805310521.WAA19570@rah.star-gate.com>
In-Reply-To: Your message of "Sun, 31 May 1998 15:09:57 %2B1000." <199805310509.PAA13433@cimlogic.com.au> 

next in thread | previous in thread | raw e-mail | index | archive | help

{hasty} ldd Barrier_Test
Barrier_Test:
        libACE.so => /usr/lib/libACE.so (0x28052000)
        libc_r.so.3 => /usr/lib/libc_r.so.3 (0x2815b000)
        libstdc++.so.2 => /usr/lib/libstdc++.so.2 (0x281e3000)
        libg++.so.4 => /usr/lib/libg++.so.4 (0x2821a000)
        libm.so.2 => /usr/lib/libm.so.2 (0x28257000)
        libc.so.3 => /usr/lib/libc.so.3 (0x28271000)
        libc_r.so.3 => /usr/lib/libc_r.so.3 (0x2815b000)
        libstdc++.so.2 => /usr/lib/libstdc++.so.2 (0x281e3000)
        libg++.so.4 => /usr/lib/libg++.so.4 (0x2821a000)
        libm.so.2 => /usr/lib/libm.so.2 (0x28257000)

Looks like I am pulling the right libraries. I will browse at the
code a little bit more.

	Tnks,
	amancio


> 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?199805310521.WAA19570>