Date: Mon, 28 Apr 2003 15:38:19 +0800 From: "David Xu" <davidxu@freebsd.org> To: "Daniel Eischen" <eischen@pcnet1.pcnet.com> Cc: freebsd-threads@freebsd.org Subject: Re: pthread_join Message-ID: <001001c30d59$913d25e0$f001a8c0@davidw2k> References: <Pine.GSO.4.10.10304280029120.14065-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----=20
From: "Daniel Eischen" <eischen@pcnet1.pcnet.com>
To: "David Xu" <davidxu@viatech.com.cn>
Cc: <freebsd-threads@freebsd.org>
Sent: Monday, April 28, 2003 12:58 PM
Subject: Re: pthread_join
> On Mon, 28 Apr 2003, David Xu wrote:
>=20
> > In thr_cleanup(), joinee accesses joiner without holding joiner's =
sched lock,
> > it is possible when joinee accesses joiner, the joiner may disappear =
(canceled).
> >=20
> > if ((joiner->state =3D=3D PS_JOIN) &&
> > (joiner->join_status.thread =3D=3D thread)) {
> > joiner->join_status.thread =3D NULL;
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
My change to atomic _thr_sched_switch does not add overhead,
it just enters critical region ealier than current code, but
total number of lock and critical region is same as current
code, and gains reliable result.
> --=20
> Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001001c30d59$913d25e0$f001a8c0>