Date: Mon, 28 Apr 2003 00:58:17 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: David Xu <davidxu@viatech.com.cn> Cc: freebsd-threads@freebsd.org Subject: Re: pthread_join Message-ID: <Pine.GSO.4.10.10304280029120.14065-100000@pcnet1.pcnet.com> In-Reply-To: <007401c30d1a$da3d7f40$0701a8c0@tiger>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Apr 2003, David Xu wrote:
> In thr_cleanup(), joinee accesses joiner without holding joiner's sched lock,
> it is possible when joinee accesses joiner, the joiner may disappear (canceled).
>
> if ((joiner->state == PS_JOIN) &&
> (joiner->join_status.thread == thread)) {
> joiner->join_status.thread = NULL;
Yes, when canceling we need to take the joinee's scheduling lock.
I think we need to add a reference to the thread so it doesn't go
away while we release the current lock and take the joiner's lock.
I think processing the joiner can be done in pthread_exit() instead
of thr_cleanup(). That's the way libc_r does it; I moved it
into thr_kern in libpthread, but it doesn't need to be there.
We could also have another lock just for joins. Or use each
thread's lock. Each thread has a lock, similar to proc lock
in the kernel, but they're not currently used for anything yet.
I envisioned using the proc lock whenever we needed to modify
something in the thread, but just used the scheduling locks
because it was easier.
I'm working on some signal fixes and some other fixes to
hopefully fix your SMP problems. I want to try these fixes
before making _thr_sched_switch() atomic (your SMP changes).
--
Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304280029120.14065-100000>