PS_BLOCKED

[Julian Elischer]

On Sun, 6 Apr 2003, Daniel Eischen wrote:

> On Sun, 6 Apr 2003, Julian Elischer wrote:
> > On Mon, 7 Apr 2003, David Xu wrote:
> > 
> > > 
> > > ----- Original Message ----- 
> > > From: "Daniel Eischen" <eischen at pcnet1.pcnet.com>
> > > To: "David Xu" <davidxu at freebsd.org>
> > > Cc: <freebsd-threads at freebsd.org>
> > > Sent: Sunday, April 06, 2003 8:39 PM
> > > Subject: Re: PS_BLOCKED
> > > 
> > > 
> > > > 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
> > > > >  ...
> > > > 
> > > > I'll do some more debugging today and see if it is in the
> > > > UTS or the kernel.
> > > > 
> > > 
> > > Note that Jeff's change to signal code in kernel also broke
> > > our kse_release code, because the upcall thread is waiting for
> > > signal in kse_release too, but now it is possible the upcall
> > > thread won't receive any signal, signal is delivered to a
> > > non-upcall thread and lost.
> > > 
> > > > > > 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.
> > > > 
> > > 
> > > It can be done by add a flags to kse_mailbox.km_flags to
> > > tell kernel to not schedule an upcall.
> > 
> > If you have this behaviour, please make it an option. Possibly
> > One way to do this would be to call kse_create, with the
> > 'new-ksegrp' flag set but the mailbox pointer set to NULL.
> > 
> > However why do you want to use kse_release for this.
> > If you have only one thread in the KSEGRP then I'd call this
> > "usleep()".
> 
> It's so that the common code (called by both scope system
> threads and scope process threads) can be the same.  I don't
> want to have to add checks all over the place to see if the
> KSE is bound to a thread or not.  Also, nanosleep doesn't
> work well because you can't wake it up with a KSE mailbox
> (kse_wakeup), plus there's a race condition if you try and
> wake it up before it actually gets to the kernel to sleep.
> The kse_wakeup() call is latched, so if it gets to the kernel
> first, the next kse_release() will notice it.

you cannot wake up a thread with no upcall mailbox using kse_wakeup
because there is no thread mailbox address to match.

> 
> > I think kse_release should be left alone.
> > It should never return.
> 
> Actually, I think it should obey all the rules that system
> calls do.  If the mailbox pointer is NULL, it returns
> normally (after timing out or getting woken up); otherwise
> an upcall is scheduled.
> 
> -- 
> Dan Eischen
> 
> _______________________________________________
> freebsd-threads at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"
>