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
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/

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