PS_BLOCKED

David Xu davidxu at freebsd.org
Sat Apr 5 23:19:01 PST 2003


----- Original Message ----- 
From: "Daniel Eischen" <eischen at pcnet1.pcnet.com>
To: "DavidXu" <davidxu at freebsd.org>
Cc: <freebsd-threads at 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




More information about the freebsd-threads mailing list