RE: thread rant

From: David Schwartz (davids@webmaster.com)
Date: Mon Sep 04 2000 - 23:49:04 EST


> I've heard comments from Alan, and others in the past bashing
> threads, and I can understand the "threads are for people who
> can't write state machines" comments I've heard, but what other
> ways are there of accomplishing the goals that threads solve in
> an acceptable manner that gives good performance without coding
> complexity?

        That's a nonsensical complaint anyway, since you need to use state machines
with threads. When there's work to be done, you hand it to a thread. That
thread needs to know what state the object it's working on was in. When that
thread is finished working, that object is in some other state.

        The reason you need threads is because you may have 12,000 state machines
and 3 of them may need to be worked on at the same time. You may not know
ahead of time whether the needed work is CPU intensive, I/O intensive, or
neither.

> This is all just curiosity. I've considered trying some thread
> programming, but if it is as stupid as it sounds, I'd rather
> learn the "right" way of writing code that would ordinarily be
> done with threads, etc.. Right now, I'm using fork() all over
> the place and don't much care how much waste it is... I'd like
> to though.

        Fork is good if you really need a whole process. It's also good if you're
doing something potentially risky and can't afford to the process that is
forking fail. It makes life miserable, however, if you need tight
communication with the forked process.

        There are plenty of things I don't like about pthreads. But pthreads is not
threads. A lot of the ugliness in pthreads was to allow operating systems
that couldn't do threads right to claim to 'fully support' threading.

        One major problem with a big 'poll loop' is that you're vulnerable to
ambush. A sudden page fault from a slow disk (or worse, NFS mount *shudder*)
and your entire process screeches to a halt. Obviously, one process per
connection/task is out of the question. Threads give you a very satisfying
in-between point.

        DS

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



This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:21 EST