lkml.org 
[lkml]   [1999]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: AMIGA will use Linux, but Linux has several "multimedia-deficiencies"


On Tue, 13 Jul 1999, Steve Underwood wrote:

> Hi Marty,
>
> Marty Leisner wrote:
>
> > John Osterhout gave a good presentation at Usenix several years ago
> > about "why threads aren't always good" (or something like that).
> > You can find it on his web site (I think). It agrees with my thinking.
> >
> > It seems much of the argument of "lets use C++" is the same as
> > "lets use threads". Sometimes it is the right answer, very often
> > it is the wrong answer.
> >
> > One of the problems with threads, if it shared data gets corrupted,
> > it is very, very difficult to analyze and debug...and it appears
> > to be random in many cases...
> >
> > I've spent enough time debugging other peoples threads problems, the first
> > question I ask is "why are you using threads?" Very seldom do I get a
> > good answer to this question.
> >
> > Marty Leisner
>
> The John Osterhout presentation is a very sane and balanced assessment of the
> value of select based programming versus threads - recommended reading. I had
> a similar presentation of my own once, but his is better so I threw mine
> away. The only issue he doesn't adequately address is the scalability
> limitation of select in multi-CPU environments. I guess it was written some
> time ago, when multi-CPU systems were less significant. Perhaps he should
> update it to give a properly balanced view for 1999's systems.

The select() .vs. threads comparison does not match event-driven .vs.
thread-oriented comparison because of the select() approach to deal with
sorts of asynchronous IOs being just an hack that band-aided the badly
designed UNIX system interface.

When you plan to write a large application that will be very costly and
that will be alive for a long time, you probably donnot want your design
be polluted by considerations about the flaws of a thing like select()
that should never have existed, if the UNIX system interface hadn't been
so poor in the first place.

Note that you can do things not too bad with select(2), if you can scale
you application by doing multiple processes handling a not too high number
of contexts.

A good O/S must not constraint you to a design you donnot want for your
application, but shall allow you to design your application as you think
it will be the best possible.

The thread-mania began with OS2. With this one (not two:) ), you were
forced to use threads in order to deal with events asynchronously in your
application. Even on this defunct OS, you could port mostly cleanly
event-driven applications. The trick was to use some specialized threads
that dealt with completions and kick ass the main thread appropriately.
This was not perfect, but this allowed clean ports.

To people that want to shoe-horn multiple threads in most applications,
I will say: just think of your children that will have to maintain all
these applications and you will probably review your opinion. ;-)

Gérard.



-
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:52    [W:0.800 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site