Messages in this thread |  | | From | Marty Fouts <> | Subject | RE: thread rant | Date | Sat, 2 Sep 2000 16:26:39 -0700 |
| |
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/
|  |