libkse and SMP (was Re: USB bulk read & pthreads)

[Daniel Eischen]

On Sat, 24 May 2003, Terry Lambert wrote:

> Daniel Eischen wrote:
> > On Fri, 23 May 2003, Terry Lambert wrote:
> > > I'm rereading it, but I don't see that interpretation.
> > >
> > > I guess if both you and Julian both called me on it, I must
> > > have misexpressed myself, but I currently don't understand
> > > how.  8-|.
> > 
> > I think it was the part about "a single CPU system with
> > PTHREAD_SCOPE_PROCESS (the default) can still get itself
> > blocked in the kernel by a single blocking call" without
> > mentioning that it won't block other scope process
> > threads from being run.
> 
> OK... this I don't get.  If the scope is process, and you
> are implementing M:N, and N == 1, my understanding of the
> code is that it will block exactly the same as libc_r.  If
> it won't (and I'm prepared to believe this), then I'd like
> to know "why not?"; it should be that there is a single
> scheduling object, no?

It will not behave the same as libc_r.  When a thread blocks
in the kernel, the kernel issues an upcall to the library
(on the same KSE) and the library chooses another thread
and runs it.  And so on, and so on, ...  When threads
unblock in the kernel, upcalls are also made to notify
the library that those threads can be resumed.  Unlike libc_r,
just because a thread blocks in the kernel doesn't mean that
the library won't be able to run other threads.

This is the KSE system's raison d'etre.  I was pretty sure
you knew how all this worked...  It makes me think we're
talking about different things.  kse(2) has some good stuff
in it.

> Reading the code, I don't get that there will be the ability
> to do multiple returns.  Is it that a KSEG is intended to
> represent a quantum?  If so, I've just had an epiphany as to

No, the KSE has the quantum.  The KSEG has the _kernel_
priority.

> why you would want KSEG's at all in the first place (I've
> never agreed with Julian on KSEG's, since the earliest days,
> and I've only reluctantly accepted their necessity as an
> artifact of scheduling priority differences for a strictest
> compliance with POSIX mandated semantics -- hence my defense
> of them to Jeff when he wanted to change the kernel code to
> make them semi-impossible).

I didn't really see the need for them either, but it is a
way to have a thread group with multiple KSEs and the same
kernel priority...

-- 
Dan Eischen