From a fundamental perspective, threads are seriously flawed as a computation model because they are wildly nondeterministic[…] The programmer's job is to prune away that nondeterminism. We have developed tools to assist in the pruning: Semaphores, monitors, and more modern overlays on threads offer the programmer ever more effective pruning. But pruning a wild mass of brambles rarely yields a satisfactory hedge.To offer another analogy, a folk definition of insanity is to do the same thing over and over again and expect the results to be different. By this definition, we in fact require that programmers of multithreaded systems be insane. Were they sane, they could not understand their programs.
Discussion (8)
Bah. There's nothing wrong with threads.
Mutexes and thread locals are pretty simple concepts and once you have them thread programming is relatively easy.
Unix programmers don't like them I know... ESR's rebuttal in TAOUP is a good one; I'm not sure I like them, but they're not complicated.
And to respond directly to the passage above: I think there are a lot of people who are "insane" who are programmers.
I don't mean this in an hilarious "you don't have to be mad to work here but it help" silly hat wearing kind of way. I mean that people who are highly defective at other things (like parties or washing their hair) can be highly effective programmers.
I should qualify my "bah" and say I don't think there's anything wrong with "goto" either.
I didn't make a claim about liking or disliking threads; I made a claim about the difficulty of reasoning about threads. The bit about insanity I thought was cute, but doesn't need to be taken literally to agree with the claim.
Would you agree that it's harder to reason about a threaded program than a non-threaded program?
No. It would depend entirely on what the non-threaded program was.
Having written web servers and web client with both I think threads are a lot easier than async IO for example.
I kind of like the approach taken by Perl's modern threading: all variables are thread-local unless declared otherwise. I haven't used it much in practice, though.
Second to that, Java did a pretty good job of integrating threading into the language. It's one of the few things for which I give Java mad props.
Enjoy your deadlocks, nic.
Deadlocks are not unique to threaded programming at all cygnus as I'm sure you know.
Indeed.