[lkml]   [1999]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kernel thread support - LWP's
On Fri, Jul 16, 1999 at 06:58:37AM +0000, Steve Underwood wrote:
> Mike Touloumtzis wrote:
> > On Fri, Jul 16, 1999 at 02:46:15AM +0000, Steve Underwood wrote:
> > Nils Nieuwejaar - Sun High Performance Computing wrote:
> > > 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?

This discussion is starting to eat its own tail. If you have a problem
that easily maps on to the event-based model then yes, the state can
generally be captured in a simple structure.

The point I was trying to make was that not all problems have a neat
mapping on to that model, including the one mentioned by the original
author. For those problems, it is technically possible to implement them
with event-based techniques, but doing it quickly and correctly is a
difficult and time-consuming task - on par with writing a special-purpose
threads library.

> > The overhead is not performance overhead -- it's
> > development overhead. Threads offer two interrelated
> > RAD gains:
> Eh? The original context was about performance.

No, the original context was about developer time:

>>>> In cases where developer time (or time to market) is at a premium...
>>>> ....Given the problem(s) we had to solve with it, threads saved us
>>>> many man-months of development effort and were the right answer.

> In most event oriented programs the "run this event to completion" strategy
> works well.

This assumes that an "event" can actually run to completion in a
reasonable amount of time. If an "event" requires processing an
arbitrary amount of data, then clients who only need a few kilobytes of
data can spend a long time waiting for a multi-gigabyte-requesting
client's "event" to run to completion.

Of course, one could argue that we should break down the multi-gigabyte
"event" into many smaller "events". To do that, we need to keep track of
how much of the data the preceding "events" have processed, which data is
in memory now, which data can safely be written to disk, how much of the
processed data has been shipped off to the client, any intermediate
results (which may incorporate arbitrary amounts of data themselves) that
were generated during the preceding processesing "events", and so on.

Of course this is possible, but is it really easier and more natural than
creating a thread to handle the long-running request, and keeping all
that state on the thread's stack?

> 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".

I'm not an event hater. There are plenty of applications in which an
event-based model is the Right Thing to use. However, there are also
plenty of applications that don't map nicely on to that model. I don't
like the attitude I've seen in this (ahem) thread, which seems be be, "if
I _can_ shoehorn this into an event-based model, then I _should_ use that

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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