Messages in this thread | | | Date | Fri, 16 Jul 1999 06:58:37 +0000 | From | Steve Underwood <> | Subject | Re: kernel thread support - LWP's |
| |
Mike Touloumtzis wrote:
> 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:
Eh? The original context was about performance. However, I've never seen a genuinely threaded solution developed more rapidly than an event driven version might be.
> -- 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.
In some programs this may be significant, but I wouldn't agree this is broadly true. I find the constant drift towards programs that have more complex interactions with their environment has, over the years, forced the explicit codifying of at least some state information in almost all programs. Only programs with the simplest of interactions with the outside world could completely avoid this.
> -- 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".
In most event oriented programs the "run this event to completion" strategy works well. This ensures the minimum of wastage in context switching, and can usually achieve the highest total throughput. That tends to be the fairest of them all. I've never found this a major drag on my development resources.
> 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.
There are a number of threaded programs with virtually no thread-to-thread interaction. In other words they have no need to be threaded at all. Independent, or minimally co-operating traditional Unix processes would achieve much same result, with greater task-to-task protection. They have no real threaded qualities, and present no particular debug problems.
There are other threaded programs which really take advantage of threads, and introduce numerous asynchronous interactions. Try convincing someone developing life critical apps. that these are amenable to thorough debug.
I'm not a thread hater. They are a valuable tool for SMP scaling, and an elegant way to implement certain programs. They are very much oversold, though. I don't like the attitude I see too often that "I'll be old fashioned if I don't use threads". Its rather like "I'll be old fasioned if I don't use NT", and just about as good for system reliability.
Steve
- 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/
| |