I'm confused. Threads are harder than *what* to get right?
If you need concurrency, you need concurrency, and any existing model is
hard. Besides, at some level, all of the concurrency models come down to a
variant on threads, anyway.
-----Original Message-----
From: Alexander Viro [mailto:viro@math.psu.edu]
Sent: Saturday, September 02, 2000 1:07 AM
To: dean gaudet
Cc: Mike A. Harris; Michael Bacarella; Linux Kernel mailing list
Subject: Re: thread rant
On Sat, 2 Sep 2000, dean gaudet wrote:
> the thread bashing is mostly bashing programs which do things such as a
> thread per-connection. this is the most obvious, and easy way to use
> threads, but it's not necessarily the best performance, and certainly
> doesn't scale. (on the scalability side just ask yourself how much RAM is
> consumed by stacks -- how many cache lines will that consume, and how many
> TLB entries. it sucks pretty fast.)
> state machines are hard. while people on linux-kernel may be hot shot
> programmers who can do state machines in their sleep, this is definitely
> not the case for the average programmer.
>
> fortunately fully threaded and fully state driven are two opposite ends of
> a spectrum, and there are lots of useful compromises in between where
> threads are used in a way that allows the average programmer to
> maintain/extend a codebase; while also getting the scalability of state
> machines.
Lovely. You've completely sidestepped the main part:
*threads* *are* *hard* *to* *write* *correctly*
Average programmer will fuck up and miss tons of race conditions. Better
than average programmers do. If you've got shared resource - you are in
for problems. Threads are useful. But they take more efforts and are much
harder to debug _and_ to prove correctness. In other words, that's one of
the last resort tools, not the first one. If you can do it without shared
state - don't bother with threads. Same as with rewrite in assmebler - do
it with small critical parts and don't unless you absolutely have to. The
first rule of optimisation: don't. Keep the critical sections small and if
you can avoid them - it's worth the efforts. You'll win a lot when it will
come to changing the thing. And you will have to change it, sooner or
later. Same goes for debugging. Non-threaded code is easier to understand.
Yes, you may be very clever. But you'll have to debug it on Friday evening
after a hard week when you want only one thing - go home and sleep. Or
somebody else will and he will curse you. KISS. And threads are _not_
simple.
-
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/
-
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:14 EST