viro@math.psu.edu (Alexander Viro) wrote on 02.09.00 in <Pine.GSO.4.10.10009020352270.9425-100000@weyl.math.psu.edu>:
> *threads* *are* *hard* *to* *write* *correctly*
Not really.
The real problem is that threads - just like pointers, incidentally -
react *far* worse to getting it wrong than most abstractions do, that is,
threads (and pointers) are often hard to debug.
And like all abstractions, they don't do you much good unless you have a
sane way of describing your problem in the terms of this abstraction.
Once you *do* have that, however, threads can be a really nice fit for
your problem. Just don't try to force-fit them on something different.
All of this, of course, is looking from the programming-abstraction point
of view. It's much harder to get right from the performance-sucks point of
view.
(Fortunately, getting it right the first way can lead to getting it right
the second way.)
Essentially, it usually comes down to the same thing: get a good high-
level description of your problem. Without it, you're fucked.
*That* is where the most energy should be spent.
Then, code it, and debug it.
> Average programmer will fuck up and miss tons of race conditions. Better
s/Average/Inexperienced/ or you have a serious documentation problem.
Which happens. of course.
> 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
Often easier than pointers, IME.
Of course, in both cases using some conventions can help bigtime.
> the last resort tools, not the first one. If you can do it without shared
In my current job project, structure went state machines -> coroutines ->
threads. Both conversions eliminated buttloads of bugs. I wish I had
started out with threads in the first place (it wasn't possible in the
circumstances). That would have solved *so* much headache.
And there was the equivalent of race conditions even back in the state
machine version. Except they were *much* harder to solve there.
Oh, and the code still has state machines - *where they make sense*.
Something with several tens of KB of internal state and complex logic
isn't where they make sense.
(Oh, and as to "one thread per connection doesn't scale" argument: thread
overhead say 8KB, connection local data 50-200KB - if the *thread*
overhead kills you, you were dead anyway.)
> state - don't bother with threads. Same as with rewrite in assmebler - do
I've never seen a problem solved with threads that *didn't* have shared
state. Ok, some only had shared state in the file system, so I know what
you mean :-)
In any case, the canonical example of a program that absolutely *MUST*
have threads is an OS kernel. You can crunch it down to a micro kernel,
but that sucks in other ways, and your servers will probably need their
own threading anyway.
> it with small critical parts and don't unless you absolutely have to. The
Right; the assembler problem is vastly different, though: here, you're
*giving up* abstractions. Don't do that unless you have no choice.
> 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
That's why the threaded version of this project often uses producer-
consumer message queues for internal communication. Much easier to get one
queue right than three dozen shared variables, all subtly different.
Another case of "chose the right abstraction".
> 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.
Not for inherently parallel stuff it's not. Definitely not. Complex state
machines are *hard* 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
And that was often when I said "I wish I had threads instead of these
bloody state machines". Now I have, and boy has it helped a lot.
> somebody else will and he will curse you. KISS. And threads are _not_
> simple.
In this you're wrong.
MfG Kai
-
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:13 EST