Messages in this thread | | | Date | Thu, 15 Jul 1999 23:01:54 -0700 | From | Mike Touloumtzis <> | Subject | Re: kernel thread support - LWP's |
| |
On Fri, Jul 16, 1999 at 02:46:15AM +0000, Steve Underwood wrote: > Nils Nieuwejaar - Sun High Performance Computing wrote: > > > To switch to an event-based model, that implicit state would have > > to be explitly saved and restored when processing other events. > > Depending on the application, that state could be arbitrarily > > complex, and saving/restoring it could be hard to do quickly and > > correctly. Once you've written all the save/restore code, you've > > essentially written your own special-purpose user-level threading > > library, and each 'event' is really just a 'context switch'. > > In most event based programming state is captured in some form of > structure or object. When you switch contexts you just point to a > different object. Where is the high overhead of saving state in that? >
The overhead is not performance overhead -- it's development overhead. Threads offer two interrelated RAD gains:
-- They free the developer from being forced to decide exactly _how_ to save state (they essentially give you "closures", as Nils points out). You don't have to codify your states.
-- They free the developer from being forced to decide the time granularity of work that should be performed in response to a given event in order to achieve "fairness".
People who dismiss threaded development often ignore these gains (and tend to exaggerate the difficulty of threaded debugging). Not every app needs to be a hand-tuned ultra-scalable performance machine.
Unfortunately, this convenience is seductive. It tempts application authors to pursue a straightforward threaded model when scalability demands merit a more hand-tuned approach. This malady apparently infected the Java designers as well.
In terms of Linux kernel threads, let me add that I'd love to have a CLONE_SIGGRP or whatever would allow Posix thread signal semantics to be cleanly implemented. Not because I'm a slave to Posix, but because I've got an embedded OS emulator that runs under Linux and which does preemptive userspace context switching. Posix signal delivery semantics would have saved me from having to worry about certain race conditions. But this is hardly a typical usage case...
miket
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |