Re: Threads question

Stefan Monnier (monnier+/news/lists/linux/kernel@TEQUILA.SYSTEMSZ.CS.YALE.EDU)
26 Apr 1997 01:29:14 -0400

Todd Graham Lewis <> writes:
> Why is it that I only post to play devil's advocate, and end up getting
> the crap beaten out of me? You think I'd learn.

Let me take on the devil's work (since he appears to be absent)!

Listen more carefully to what all those guys said:

"it's far better, performance-wise, to have a queue of events which are
processed by a dynamic number of worker threads"

I could translate it into:

"it's far better, performance-wise, to multiplex a queue of
super-lightweight-threads on a dynamic number of kernel threads"

Your "events" in the queue just happen to be a custom-designed representation
of each thread's context: that's why it's more efficient than a run-of-the-mill
thread. But if your run-of-the-mill thread package is lightweight enough (and
multiplexed on top of some kernel threads), the simplification of your code can
be worth it.
In other words, it depends on how lightweight your thread package can be (in
SML/NJ, for instance they can be extremely lightweight: sharing parts of their
stacks, only saving the "live" registers, ...) and on how much lighter you
can represent the state of each of those threads into a custom-designed "event"

So a user-level threads package on top of kernel threads still makes sense to
me, but it needs to be ultra-lightweigt:
- such threads don't understand signals, don't duplicate anything that is not
strictly necessary.
- they can't use MMU-tricks to check their stack accesses (since this would
imply the dreaded 1-page per thread lower bound)
- they will be non-preemptive (which is OK since you still have preemption at
the kernel-thread level). It would be nice also to be able to flag the
"yield" call as "doesn't obey the callee-save convention" to reduce some more
the cost of switching.

The problem is that very soon people find that they want this little extra
feature, and then that one and before you know it, your threads package is not
quite so light any more. In other words, it can only work if you manage to make
your package extensible "from the outside" by stacking feature on top of it
only when necessary.