If you are building an OS kernel, database kernel, or writing high-performance computational code (after having prototyped a low-performance version, and made sure that the high-level algorithmic design is sound) then must be picky about the libraries you use anyway.

If you are writing a quick script, then you don't want to be picking through your libraries source code for thread safety.

But 99% of people who use threads are just looking to keep a GUI looking responsive, which only takes a couple of processes anyway. Sand-boxing different components into their own process seems to be the way players like Google (Chrome) and Apple (Lion) are going anyway.

While threads have their place, I think it's the same kind of place that inlined assembly should be considered.

They certainly do, but I'm very skeptical when I'm told that a language/runtime cannot do X because in 95% of all cases X is the wrong thing to do.

What about the other 5%? Working around the lack of threads in those remaining instances takes orders of magnitude more work. Anyone who has ever implemented complex data structures in shared memory or memory mapped files knows that. No pointers, no new/delete/malloc/free, no garbage collector, just a big blob.

It's definitely more difficult than using only a few well documented, high quality, libraries in the parts of the code where it matters.

Except deadlocks have nothing to do with sharing memory, and everything to do with sharing state. Shared state is necessary whether your address space is shared or not, and deadlocks will always be a risk in complex systems, whether the components involved are in the same or different processes.

Anyway, I'm mostly a server-side engineer, so I can't speak well to the disastrous mess of GUI libraries and such, but the libraries I use are, indeed, thread-safe, and I'm quite confident that they will remain so. Their state is maintained through handles, not global variables.

I did a bunch of research for my PhD thesis on this, and came to the conclusion that "the probability of concurrency errors is proportional to the square of the amount of shared state". Threads share state by default, which brings significant risk.

Also server side engineers aren't necessarily safe; there are a number of C library functions that are not particularly reentrant. This has been known for decades because reentrancy is important in signal handling situations. The safest way of dealing with asynchronous signals, in fact, is to use global flag variables and use the flag as an indication that one should e.g. call waitpid because at least one SIGCHLD has come in since you last went through the main loop. You may deny that this happens particularly often, but that particular hack was an important simplification of my life a few months ago.