Date: Sun, 6 Apr 2003 15:23:30 +0800 From: "David Xu" <davidxu@freebsd.org> To: "Daniel Eischen" <eischen@pcnet1.pcnet.com> Cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED Message-ID: <000d01c2fc0d$6d404c60$0701a8c0@tiger> References: <Pine.GSO.4.10.10304060127430.24320-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Daniel Eischen" <eischen@pcnet1.pcnet.com> To: "DavidXu" <davidxu@freebsd.org> Cc: <freebsd-threads@freebsd.org> Sent: Sunday, April 06, 2003 2:40 PM Subject: Re: PS_BLOCKED > 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. > Congratulation! I know ACE is a big monster, it is a very practical test suit. > 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. > I don't know if Jeff's signal change in kernel affects your code, but signals lost problem is still not fixed, a thread exports its context and exits would lost signals dispatched to it, even the signals is not for the thread, but for process. > 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? A new upcall will be scheduled, does not return. > 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()? > Yes, you can use kse_wakeup to interrupt it, pass the kse mailbox address to the syscall. > -- > Dan Eischen > > > Let's Go Orange! Would there be a new patch against code in the src tree I can download ? David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000d01c2fc0d$6d404c60$0701a8c0>