lkml.org 
[lkml]   [1999]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.044 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site