PS_BLOCKED
Daniel Eischen
eischen at pcnet1.pcnet.com
Sun Apr 6 05:39:52 PDT 2003
On Sun, 6 Apr 2003, David Xu wrote:
>
> ----- 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.
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
More information about the freebsd-threads
mailing list