Bill Studenmund <wrstuden@netbsd.org> writes:

> Subject says most of it.
>
> So how exactly do we do M:N threads w/o SA?

It's been roughly 20 years since the last time i was involved in
implementing M:N, so it's going to take me a while to reconstruct the
details. (or reinvent them, I guess.)

> As I understand it, you want CONCURRENCY threads running at once.
> Obviously you need CONCURRENCY CPUs to really do that.

Yes.

> When a thread blocks in the kernel, you'd like to run something else on 
> that thread, no?

Yes. This is why I don't believe you can accomplish this entirely in
userland.

> Thus you have to somehow let the scheduler in userland schedule a
> new thread onto the virtual CPU you were using.

Yes.  But "Scheduler Activation" is only one such mechanism.

> If you do nothing, you eventually have all your threads stuck in the 
> kernel, even if there's more work to do in userland. ??

Yes.  Well, hopefully they'll all get unblocked again.

> Or is the idea a different way of communicating to userland?

Yes.  The underlying problem is that you need to find a way to limit
the knowledge of blocking to the scheduler itself and not disperse it
through the kernel. The trick is to have the library level scheduler
'register' with the kernel level scheduler and have the kernel level
scheduler check whenever it's rescheduling because of a blocked lwp.
It's really not that hard, if you're willing to settle for "good
enough".