On Apache/1.3.37 (Unix) mod_throttle/3.1.2 FrontPage/5.0.2.2635 mod_psoft_traffic/0.2 mod_ssl/2.8.28 OpenSSL/0.9.8b
Under GNU General Public License
2009-01-07 21:23 @38.103.63.55 Crawled by CCBot/1.0 (+http://www.commoncrawl.org/bot.html)
PTHREADS(7) Linux Programmer's Manual PTHREADS(7)
NAME
pthreads - POSIX threads
DESCRIPTION
POSIX.1 specifies a set of interfaces (functions, header files) for threaded pro-
gramming commonly known as POSIX threads, or Pthreads. A single process can con-
tain 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 variables).
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())
- nice value (setpriority(2))
- resource limits (setrlimit(2))
- measurements of the consumption of CPU time (times(2)) and resources
(getrusage(2))
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())
- the errno variable
- alternate signal stack (sigaltstack(2))
- real-time scheduling policy and priority (sched_setscheduler(2) and sched_set-
param(2))
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:
- LinuxThreads This is the original (now obsolete) Pthreads implementation.
- 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 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 synchronisation primitives (mutexes, thread joining, etc.) are implemented
using the Linux futex(2) system call.
Modern GNU C libraries provide both LinuxThreads and NPTL, with the latter being
the default (if supported by the underlying kernel).
LinuxThreads
The notable features of this implementation are the following:
- In addition to the main (initial) thread, and the threads that the program cre-
ates using pthread_create(), the implementation creates a "manager" thread.
This thread handles thread creation and termination. (Problems can result if
this thread is inadvertently killed.)
- 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 imple-
mented 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 thread.
- 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 spe-
cific 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 sig-
nals on their shared alternate signal stack at the same time, unpredictable pro-
gram failures are likely to occur.)
NPTL
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 a few non-conformances 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).
Determining the Threading Implementation
Since glibc 2.3.2, the getconf(1) command can be used to determine the system's
default 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 libc.so | 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, 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 (bro-
ken) application that depends on some non-conformant behavior in LinuxThreads.)
For example:
bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep libc.so | \
awk '{print $3}' ) | egrep -i 'threads|ntpl'
linuxthreads-0.10 by Xavier Leroy
SEE ALSO
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_set-
canceltype(3), pthread_setspecific(3), pthread_sigmask(3), and pthread_testcan-
cel(3).
Linux 2.6.12 2005-06-07 PTHREADS(7)
Generated by $Id: phpMan.php,v 4.49 2006/02/26 13:18:18 chedong Exp $ Author: Che Dong
On Apache/1.3.37 (Unix) mod_throttle/3.1.2 FrontPage/5.0.2.2635 mod_psoft_traffic/0.2 mod_ssl/2.8.28 OpenSSL/0.9.8b
Under GNU General Public License
2009-01-07 21:23 @38.103.63.55 Crawled by CCBot/1.0 (+http://www.commoncrawl.org/bot.html)