Date: Sun, 6 Apr 2003 01:40:50 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: DavidXu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED Message-ID: <Pine.GSO.4.10.10304060127430.24320-100000@pcnet1.pcnet.com> In-Reply-To: <002c01c2fbec$b23756e0$0701a8c0@xu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 Apr 2003, DavidXu wrote: > Daniel, > > I saw your code in thr_kern.c assumes that a blocked thread > in kernel will always be returned in same upcall(your userland > kse)? However, current kernel will returned this context in one > of upcall in the same ksegrp, so there is race in your code, > I think this may be a kernel bug but not yours, this does not > very respects original paper. Hey, glad to see you got through to an @freebsd.org list from home (I presume)! Actually, I got rid of PS_BLOCKED earlier today. I think I deal with blocked threads OK now and I don't think I assume (any longer) that they belong to any particular KSE. I've made some decent progress and can run the mutex test sucessfully, and can run most of the ACE tests also. Some of the ACE tests fail, but some also fail with libc_r (I don't think it's the threads library). I'm running them with libc_r now and will compare against libkse. I've still got one bug I am trying to hunt down with signals -- the sigwait test fails. Process (kill) signals don't seem to wakeup threads in sigwait(). I'm not sure if it is a kernel bug or not, but I suspect it's something I'm doing. One question. What happens when kse_release(tsp) is called when k_mbx.km_curthread == NULL? Does it just return after the timeout, or is there a new upcall? And if kse_A->k_mbx.km_curthread == NULL and it is in a kse_release(tsp), can another kse interrupt it (before the timeout) with kse_wakeup()? -- Dan Eischen Let's Go Orange!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304060127430.24320-100000>