lkml.org 
[lkml]   [2001]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Alan Cox quote? (was: Re: accounting for threads)
    Date
    On Tuesday 19 June 2001 12:52, Larry McVoy wrote:
    > On Tue, Jun 19, 2001 at 05:26:09PM +0100, Matthew Kirkwood wrote:
    > > On Tue, 19 Jun 2001, Larry McVoy wrote:
    > > > ``Think of it this way: threads are like salt, not like pasta. You
    > > > like salt, I like salt, we all like salt. But we eat more pasta.''
    > >
    > > This is oft-quoted but has, IMO, the property of not actually
    > > making any sense.
    >
    > Hmm. Makes sense to me. All it is saying is that you can't make a good
    > dinner out of a pile of salt. It was originally said to some GUI people
    > who wanted to use a thread per object, every button, scrollbar, canvas,
    > text widget, menu, etc., are all threads. What they didn't figure out is
    > that a thread needs a stack, the stack is the dominating space term, and
    > they were looking at a typical desktop with around 9,000 objects. Times,
    > at that point, an 8K stack. That was 73MB in stacks. Pretty darned stupid
    > when you look at it that way, huh?

    I've seen worse.

    Back around '93 or so I took a look at Linux and wound up putting OS/2 on my
    desktop instead of Linux for 2 reasons.

    1) Diamond Stealth video card. It worked in OS/2, didn't work in Linux, and
    the reason was you guys couldn't get vendor support while IBM could.
    According to this list, it was entirely possible this sort of problem would
    NEVER be addressed. (We got around it with reverse engineering and critical
    mass, but at the time hardware was changing way faster than we could keep up
    with it.)

    2) Not only did Linux not have threads (at all), it didn't plan to have
    threads, and anybody who brought up the idea of threads was dismissed.
    Considering this was long before clone, and SMP hardware was starting to come
    into the high and and looked like it might wind up on the desktop eventually
    (who knew MS would keep DOS around another ten years, unable to understand
    two processors, to displays, two mice, two keyboards, and barely able to cope
    with two hard drives under a 26 letter limit...)

    So I wound up work at IBM doing OS/2 development for a couple years. On a
    project called Feature Install, which was based on a subclassed folder in the
    workplace shell (object oriented desktop). The idea was you fill up a folder
    with files, drag and drop them from diskette to desktop, and they install
    themselves automatically. (Went out the window when a single install object
    had to span two disks, but oh well. By then, they were stuck with the
    design. I inherited it after a year or two of scar tissue had accumulated.)

    They created THREE threads for every single object, and they objects could
    nest arbitrarily deep. (Modular installs with sub-components.) The OS had a
    default of 1024 threads (expandable to 4096, I believe, before they hit a 64k
    limit somewhere in the coding). When they made up a test object hierarchy
    for all the components of the entire OS, it created so many threads the
    system ran out and got completely hosed. I had a command line window open,
    but couldn't RUN anything, since anything it tried to spawn required a thread
    to run. (Child of the shell.)

    One three finger salute later, the desktop comes back up automatically, with
    this nasty tangle of objects STILL there, and of course hoses itself AGAIN as
    the desktop instantiates all those objects in memory with their three threads
    apiece, and runs out again...

    Those were the days. If I remember correctly, I replace ALL those threads
    with a single thread doing all the work, a mutex protected linked list of
    work to do, and an event semaphore to tell it to do it.

    > Nobody is arguing that having more than one thread of execution in an
    > application is a bad idea. On an SMP machine, having the same number of
    > processes/threads as there are CPUs is a requirement to get the scaling
    > if that app is all you are running. That's fine. But on a uniprocessor,
    > threads are basically stupid.

    Sometimes they're an easy way to get asynchronous behavior, and to perform
    work in the background without the GUI being locked up. But the difference
    between "processes" and "threads" there is academic. Processes with shared
    memory and some variant of semaphores to avoid killing each other in it.
    Same thing.

    And I think the most I've ever REALLY used is about three for a whole
    program. (Unless you're talking about a server with a thread pool handling
    connections. And yeah that could be done with poll and non-blocking I/O, but
    not if you're shelling out to ssh and such...)

    > The only place that I know of where it is
    > necessary is for I/O which blocks. And even there you only need enough
    > to overlap the I/O such that it streams. And processes will, and do,
    > work fine for that.

    And nonblocking GUI elements, and breaking up work for multiple processors,
    and probably a few other things.

    But I think the MAIN difference between the two camps is that the people who
    despise threads consider them to be a lot different from processes, and the
    people who like threads consider it a semantic argument. I worry about cache
    trashing with too much shared data in an SMP system, but like the fact you
    automatically have synchronization primitives in a threading environment
    which might not be there if you're just dealing with processes.

    I've used the filesystem for synchronization. Back around 1991 I wrote my
    own fidonet compatable multinode BBS under DOS with desqview, including the
    mail tosser, from scratch in Borland C++ with nothing but file locking to
    keep the instances from killing each other, and I got 30 messages/second
    throughput on a 33 mhz 386. The mail tosser could catch new posts in the
    middle of a stream of incoming messages from the network without ever having
    to look at an individual message message twice, and packed the message bases
    during the act of posting. (And a bunch of fancy features I won't bore you
    with, especially the way delete worked.)

    After doing all that with stone knives and bearskins, I -APPRECIATED- a 32
    bit flat memory model with threads. :)

    > I think the general thrust of us ``anti-thread'' people is that a few
    > are fine, a lot is stupid, and the model encourages a lot. It's just
    > like perl5, C++, pick-your-favorite-feature-rich-language in that
    > exceptional programmers will do a good job with the problem but average
    > programmers will do a horrible job. Given that there are only a few
    > exceptional programmers and a never ending wave of average programmers,
    > the argument is that one should tailor the paradigm for the common case,
    > not for the exceptional case.

    There has not been and never will be a language in which it is the least bit
    difficult to write bad programs.

    I don't remember who said that, but it should be on your list. (Ask Nancy
    Lebowitz.)

    Bondage and discipline languages that enforce somebody's idea of good
    programming practice usually just result in WORSE bad programs, and fewer
    good programs written by people who know how to play with fire without
    burning themselves. Saying you can't have threads because they can be
    misused and "you shouldn't program that way" would be truly dumb. (Turned ME
    off for a couple years, anyway.)

    Rob
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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