What are the common problems with threads?

Several problems with threads originate from a classic view and itsintrinsic concurrency complexity.

Classic View

In many other multithreaded OSs, threads are not processes merely partsof a parent task. Therefore, the question of "what happens if a threadcalls fork() or (worse) if a thread execve()'s some external program"becomes problematic: the whole task could be replaced. The POSIX1c standard defines a thread calling fork() to duplicate only the callingthread in the new process; and an execve() from a thread would stop allthreads of that process.

Having two different implementations and schedulers for processes isa flaw that has perpetuated from implementation to implementation. In fact,some multitasking OSs have opted not to support threads due to theseproblems (not to mention the effort needed to make the kernel and libraries100% reentrant). For example, the POSIX-compliant Windows NT does not tosupport threads (Windows NT does support threads but they are notPOSIX compliant).

Concurrency Complexity

Most people have a hard enough time understanding tasks, never mind"chopped up tasks" or threads. The first problem while programmingis answering the question: "What can be threaded in my app?".That, in itself, can be very laborious (see section on "Whatkinds of things should be threaded/multitasked?").

Another problem is locking. All the nightmares about sharing, locking,deadlock, race conditions, etc. come vividly alive in threads. Processesdon't usually have to deal with this, since most shared data is passedthrough pipes. Now, threads can share file handles, pipes, variables, signals,etc. Trying to test and duplicate error conditions can cause more grayhair than a wayward child.