Provided by: manpages_2.77-1_all bug


       pthreads - POSIX threads


       POSIX.1  specifies  a  set  of interfaces (functions, header files) for
       threaded programming commonly known as POSIX threads, or  Pthreads.   A
       single process can contain multiple threads, all of which are executing
       the same program.  These threads share the same global memory (data and
       heap   segments),   but  each  thread  has  its  own  stack  (automatic

       POSIX.1 also requires that threads share a range  of  other  attributes
       (i.e., these attributes are process-wide rather than per-thread):

       -  process ID

       -  parent process ID

       -  process group ID and session ID

       -  controlling terminal

       -  user and group IDs

       -  open file descriptors

       -  record locks (see fcntl(2))

       -  signal dispositions

       -  file mode creation mask (umask(2))

       -  current directory (chdir(2)) and root directory (chroot(2))

       -  interval timers (setitimer(2)) and POSIX timers (timer_create(3))

       -  nice value (setpriority(2))

       -  resource limits (setrlimit(2))

       -  measurements of the consumption of CPU time (times(2)) and resources

       As well as the stack, POSIX.1 specifies that various  other  attributes
       are distinct for each thread, including:

       -  thread ID (the pthread_t data type)

       -  signal mask (pthread_sigmask(3))

       -  the errno variable

       -  alternate signal stack (sigaltstack(2))

       -  real-time  scheduling policy and priority (sched_setscheduler(2) and

       The following Linux-specific features are also per-thread:

       -  capabilities (see capabilities(7))

       -  CPU affinity (sched_setaffinity(2))

   Compiling on Linux
       On Linux, programs that use the Pthreads API should be  compiled  using
       cc -pthread.

   Linux Implementations of POSIX Threads
       Over  time, two threading implementations have been provided by the GNU
       C library on Linux:

              This is the original Pthreads implementation.  Since glibc  2.4,
              this implementation is no longer supported.

       NPTL (Native POSIX Threads Library)
              This  is the modern Pthreads implementation.  By comparison with
              LinuxThreads,  NPTL   provides   closer   conformance   to   the
              requirements of the POSIX.1 specification and better performance
              when creating large numbers of threads.  NPTL is available since
              glibc 2.3.2, and requires features that are present in the Linux
              2.6 kernel.

       Both of these are so-called  1:1  implementations,  meaning  that  each
       thread   maps   to   a   kernel   scheduling  entity.   Both  threading
       implementations employ the Linux clone(2) system call.  In NPTL, thread
       synchronization   primitives   (mutexes,   thread  joining,  etc.)  are
       implemented using the Linux futex(2) system call.

       The notable features of this implementation are the following:

       -  In addition to the main (initial) thread, and the threads  that  the
          program  creates using pthread_create(3), the implementation creates
          a  "manager"  thread.   This  thread  handles  thread  creation  and
          termination.   (Problems  can result if this thread is inadvertently

       -  Signals are used internally by the implementation.  On Linux 2.2 and
          later,  the  first three real-time signals are used.  On older Linux
          kernels, SIGUSR1 and SIGUSR2 are used.  Applications must avoid  the
          use of whichever set of signals is employed by the implementation.

       -  Threads  do not share process IDs.  (In effect, LinuxThreads threads
          are implemented as  processes  which  share  more  information  than
          usual,  but  which  do not share a common process ID.)  LinuxThreads
          threads (including the  manager  thread)  are  visible  as  separate
          processes using ps(1).

       The LinuxThreads implementation deviates from the POSIX.1 specification
       in a number of ways, including the following:

       -  Calls to getpid(2) return a different value in each thread.

       -  Calls to getppid(2) in threads other than the main thread return the
          process  ID  of  the  manager  thread;  instead  getppid(2) in these
          threads should return the same  value  as  getppid(2)  in  the  main

       -  When  one  thread  creates  a  new  child process using fork(2), any
          thread should be  able  to  wait(2)  on  the  child.   However,  the
          implementation  only  allows  the  thread  that created the child to
          wait(2) on it.

       -  When a thread calls execve(2), all other threads are terminated  (as
          required  by  POSIX.1).  However, the resulting process has the same
          PID as the thread that called execve(2): it should have the same PID
          as the main thread.

       -  Threads   do   not  share  user  and  group  IDs.   This  can  cause
          complications with set-user-ID programs and can  cause  failures  in
          Pthreads  functions  if an application changes its credentials using
          seteuid(2) or similar.

       -  Threads do not share a common session ID and process group ID.

       -  Threads do not share record locks created using fcntl(2).

       -  The information returned by times(2) and getrusage(2) is  per-thread
          rather than process-wide.

       -  Threads do not share semaphore undo values (see semop(2)).

       -  Threads do not share interval timers.

       -  Threads do not share a common nice value.

       -  POSIX.1  distinguishes  the  notions of signals that are directed to
          the process as a  whole  and  signals  are  directed  to  individual
          threads.   According  to  POSIX.1,  a  process-directed signal (sent
          using  kill(2),  for  example)  should  be  handled  by  a   single,
          arbitrarily  selected  thread within the process.  LinuxThreads does
          not support the notion of process-directed signals: signals may only
          be sent to specific threads.

       -  Threads  have  distinct alternate signal stack settings.  However, a
          new thread’s alternate signal stack settings  are  copied  from  the
          thread  that  created  it,  so  that  the threads initially share an
          alternate  signal  stack.   (A  new  thread  should  start  with  no
          alternate  signal  stack  defined.  If two threads handle signals on
          their shared alternate signal stack at the same time,  unpredictable
          program failures are likely to occur.)

       With  NPTL,  all  of  the  threads  in a process are placed in the same
       thread group; all members of a thread groups share the same PID.   NPTL
       does not employ a manager thread.  NPTL makes internal use of the first
       two real-time signals; these signals cannot be used in applications.

       NPTL still has at least one non-conformance with POSIX.1:

       -  Threads do not share a common nice value.

       Some NPTL non-conformances only occur with older kernels:

       -  The information returned by times(2) and getrusage(2) is  per-thread
          rather than process-wide (fixed in kernel 2.6.9).

       -  Threads do not share resource limits (fixed in kernel 2.6.10).

       -  Threads do not share interval timers (fixed in kernel 2.6.12).

       -  Only  the  main  thread  is  permitted  to start a new session using
          setsid(2) (fixed in kernel 2.6.16).

       -  Only the main thread is permitted to make the process into a process
          group leader using setpgid(2) (fixed in kernel 2.6.16).

       -  Threads  have  distinct alternate signal stack settings.  However, a
          new thread’s alternate signal stack settings  are  copied  from  the
          thread  that  created  it,  so  that  the threads initially share an
          alternate signal stack (fixed in kernel 2.6.16).

       Note the following further points about the NPTL implementation:

       -  If the stack size  soft  resource  limit  (see  the  description  of
          RLIMIT_STACK   in  setrlimit(2))  is  set  to  a  value  other  than
          unlimited, then this value defines the default stack  size  for  new
          threads.  To be effective, this limit must be set before the program
          is executed, perhaps using the  ulimit  -s  shell  built-in  command
          (limit stacksize in the C shell).

   Determining the Threading Implementation
       Since  glibc 2.3.2, the getconf(1) command can be used to determine the
       system’s threading implementation, for example:

           bash$ getconf GNU_LIBPTHREAD_VERSION
           NPTL 2.3.4

       With older glibc versions, a command such as the  following  should  be
       sufficient to determine the default threading implementation:

           bash$ $( ldd /bin/ls | grep | awk ’{print $3}’ ) | \
                           egrep -i ’threads|ntpl’
                   Native POSIX Threads Library by Ulrich Drepper et al

   Selecting the Threading Implementation: LD_ASSUME_KERNEL
       On systems with a glibc that supports both LinuxThreads and NPTL (i.e.,
       glibc 2.3.x), the LD_ASSUME_KERNEL environment variable can be used  to
       override   the   dynamic   linker’s   default   choice   of   threading
       implementation.  This variable tells the dynamic linker to assume  that
       it  is  running on top of a particular kernel version.  By specifying a
       kernel version that does not provide the support required by  NPTL,  we
       can  force  the use of LinuxThreads.  (The most likely reason for doing
       this is to run  a  (broken)  application  that  depends  on  some  non-
       conformant behavior in LinuxThreads.)  For example:

           bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep | \
                           awk ’{print $3}’ ) | egrep -i ’threads|ntpl’
                   linuxthreads-0.10 by Xavier Leroy


       clone(2),  futex(2),  gettid(2),  futex(7), and various Pthreads manual
       pages,   for   example:   pthread_atfork(3),   pthread_cleanup_push(3),
       pthread_cond_signal(3),     pthread_cond_wait(3),    pthread_create(3),
       pthread_detach(3),          pthread_equal(3),          pthread_exit(3),
       pthread_key_create(3),      pthread_kill(3),     pthread_mutex_lock(3),
       pthread_mutex_unlock(3),  pthread_once(3),   pthread_setcancelstate(3),
       pthread_setcanceltype(3),  pthread_setspecific(3),  pthread_sigmask(3),
       and pthread_testcancel(3).


       This page is part of release 2.77 of the Linux  man-pages  project.   A
       description  of  the project, and information about reporting bugs, can
       be found at