Plus, getting multithreading "right" is not nearly as simple as it
IMHO, the biggest problem with multi-threaded applications is that
there's no really good way to debug them or perform QA on them.
Walden suggests that programmers don't "do it right", and Mark says that
the environment doesn't "hide the complexity". I agree with both of
these statements, however, for me the really important problem is, it
doesn't tell you when you're doing something that isn't threadsafe or
might create a deadlock.
There's really no good way for the compiler to detect those things.
There's really no good way for the programmer to test their apps to see
that they are doing everything in a threadsafe manner, or that they
won't create deadlocks. When something does fail during testing (or
production) there's really no way to tell what the problem is, and when
you try to debug it further (by running in a debugging tool, running a
trace on what's happening, etc) it changes the timing and therefore
doesn't reproduce the problem (at least, not the same way)
So the only way to find/fix bugs is when the programmer really groks
threads, and can imagine the problems of the program when desk-checking
the code. Anyone with programming experience knows how hard that is to do!
So I really hate multithreaded programming. Not because the OS doesn't
hide the complexity, but because it doesn't yell at me when I do