Date: Sun, 6 Apr 2003 08:39:49 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED Message-ID: <Pine.GSO.4.10.10304060821060.1170-100000@pcnet1.pcnet.com> In-Reply-To: <000d01c2fc0d$6d404c60$0701a8c0@tiger>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 Apr 2003, David Xu wrote: > > ----- 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. Yes, it's helped me find a lot of bugs in libc_r :-) > > 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. I'll do some more debugging today and see if it is in the UTS or the kernel. > > 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. Is there a way that we could get it to just return? I would like to make PTHREAD_SCOPE_SYSTEM threads (one thread per KSE/KSEG) work without a separate scheduler stack. We should be able to do everything from the thread's stack. I'd be willing to add a flag or something to the KSE mailbox to get this behaviour. > > 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. Cool, that's what I thought. I forgot to mention it, but I think I found a kernel bug also. Sometimes when the kernel exports a context to the UTS the %gs register isn't set; it doesn't seem to be saved in some instances. I think it might only be when a kernel thread is swapped out (without blocking). Does %gs always get saved, even if the thread is interrupted by an interrupt? > > -- > > Dan Eischen > > > > > > Let's Go Orange! > > Would there be a new patch against code in the src tree > I can download ? Done. I'll try to do some more debugging and update it again later today. http://people.freebsd.org/~deischen/libpthread.diffs -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304060821060.1170-100000>