You've come to this page as a result of a question similar to the following:
What are the known problems with threads on Linux?
This is the Frequently Given Answer to that question.
Linux doesn't provide the rich and complete multithreaded programming semantics that people used to Unices may expect. There are quite a number of known problems with the threads implementations.
Most of these problems arise from the fact that whilst Linux was designed with the concept of "tasks that may optionally share common resources" masquerading as both threads and processes, this concept has not in fact been fully and properly implemented. The kernel functionality is incomplete. Whilst file handle tables and memory management data structures are already shared, things that must also be shareable, such as resource limit information, resource usage information, and parent process ID, are not.
And until the kernel functionality is complete, these problems will persist.
Back in 1999, when this list was first compiled, the threads implementation on Linux was LinuxThreads. And, indeed, LinuxThreads is what you will still get in Linux distributions today. In 2002-09, version 0.1 of "Native POSIX Threads for Linux" was annnounced. This is designed to make use of kernel facilities that will be available in version 2.6 of Linux. However, as of version 0.19 of NPTL and version 2.5.36 of the kernel, only some of the known problems have been addressed. Quite a lot of necessary changes to the kernel still remain outstanding.
And, of course, you won't get the corrections that have been made in any Linux distribution until they switch to NPTL and version 2.6 (or version 2.5.36 or later) of the kernel.
These are the known problems with threads on Linux:
(Claimed fixed when using NPTL with 2.5.36 kernel.) It doesn't handle signals correctly.
Signals sent via kill() from other processes are delivered
to single individual threads rather than to the process as a whole. This
makes it difficult to manually SIGSTOP a process, causes
job control to operate incorrectly, and makes it hard to implement
debuggers that can freeze a whole process.
(Claimed fixed when using NPTL with 2.5.36 kernel.)
A multithreaded process cannot perform asynchronous I/O with
SIGIO, handling the signal in a separate thread.
(Not addressed by NPTL.) ps shows every thread in a process, and moreover shows each thread as if it were a process. The traditional Unix semantics are that ps lists processes, not threads.
Commercial Unices get this right. Their ps commands list processes. Details of individual threads are simply another sort of additional information about a process that can be printed if desired. (See the -L option to ps on Solaris, for example.)
(Still outstanding, albeit unacknowledged, as of NPTL 0.19 and kernel 2.5.36.)
Core dumps of multi-threaded programs don't contain all the threads (or
even necessarily the crashing one !).
(Claimed fixed when using NPTL with 2.5.36 kernel.)
getpid() doesn't return the same value for all threads in a
single process. In fact, there is no value provided by the Linux kernel
to applications corresponding to the standard Unix concept of
process ID.
A commonly suggested workaround, that of making getpid()
save the first ID that it receives from the kernel in a static variable,
is flawed. It doesn't work across exec(), whereas a
correctly implemented getpid() must.
(Probably fixed when using NPTL with 2.5.36 kernel.)
A child process fork()ed by one thread in the parent
process often cannot be wait()ed for by a different thread
in the parent process, depending upon the exact parent-child
relationships between threads within the parent.
(Claimed fixed when using NPTL with 2.5.36 kernel.) Threads have parent-child relationships (when they should properly all be peers).
(Acknowledged as still outstanding as of NPTL 0.19 and kernel 2.5.36.) User and group ID information isn't common to all threads in a single process, so (for example) a multithreaded setuid/setgid process can have a very interesting time.
(Acknowledged as still outstanding as of NPTL 0.19 and kernel 2.5.36.)
rlimit information isn't common to all threads in a single
process.
(Acknowledged as still outstanding as of NPTL 0.19 and kernel 2.5.36.) A multithreaded session leader process cannot do things like disconnecting from a controlling TTY in any thread other than its first.
This is because the kernel associates session leadership with tasks and not with processes as it should do. Even though it is in the same session leader process, a secondary thread is not considered to be the session leader task.
(Acknowledged as still outstanding as of NPTL 0.19 and kernel 2.5.36.)
times() doesn't account for anything other than the thread
it is called in.
(Still outstanding, albeit unacknowledged, as of NPTL 0.19 and kernel 2.5.36.) Regions of files locked by different threads in the same process are not correctly merged.