Messages in this thread | | | From | Stefan Monnier <monnier+/news/lists/linux/> | Subject | Re: Threads question | Date | 26 Apr 1997 01:29:14 -0400 |
| |
Todd Graham Lewis <lists@reflections.eng.mindspring.net> 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" structure.
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.
Stefan
| |