pthreads(5) pthreads(5)
NAME
pthreads - introduction to POSIX thread characteristics
DESCRIPTION
This man page is intended as an overview of the POSIX thread model as
implemented in IRIX; it is not an introduction to thread programming or a
detailed description of the IRIX implementation.
Thread programming is motivated by two concerns:
Application Performance
⊕ On a multiprocessor multiple threads may run at the same time.
⊕ Operations that cause the caller to wait do not prevent other
threads (in the same process) from making progress.
Programming Model
⊕ Complex applications can be structured more elegantly by
partitioning with threads.
⊕ Threads share many resources implicitly which can simplify co-
operative algorithms.
In the past a UNIX process has been thought of as having a single thread.
The POSIX thread programming model (known as pthreads) introduces the
concept of multiple threads within a single process. A POSIX thread is
an executable entity that belongs to a process. It contains sufficient
state to enable it to run on a processor independently of its fellows.
In most other respects threads share state with their host process. The
vast majority of interfaces and features work the same way in a multi-
threaded process as an unthreaded one.
The POSIX threads API provides a set of interfaces and semantics for
creating and controlling threads. Because the interfaces are defined by
the ISO standards organisation an application using them may enjoy the
benefits of parallel programming without sacrificing portability.
Applications
To create a pthread process an application must be linked with the
pthread run-time library. It is also recommended that the thread safe
options be enabled at compile time using the feature test macro,
POSIXCSOURCE.
cc -D_POSIX_C_SOURCE=199506L app.c -llib0 -llib1 ... -lpthread
See intro(3), section 3P for further details.
Components
POSIX threads introduces a number of thread components.
Attribute
An attribute is a characteristic of something that defines its
behaviour. Most of the objects introduced by pthreads have
characteristics which are set when it is created; indeed some
Page 1
pthreads(5) pthreads(5)
characteristics may only be set at that time. A set of
characteristics may be specified in an attribute object which is
passed to the creation interface. An analogy is a mould or template
that is used to shape some artifact. Every attribute has a default
value and the attribute object itself is optional.
Thread
A thread executes code. It is created using pthread_create() and
either inherits characteristics from its creator or has them
specified via creation attributes. The pthread_attr_* interfaces
may be used to create a thread attributes object.
Many features of the process are shared by its threads, including
process and user ids (PID, UID), file descriptors, memory (including
text and data) and signal handlers.
Each thread has a unique identity which is used by a number of
pthread interfaces. Thread ids may be compared using
pthread_equal().
Threads terminate with an exit status [see pthread_exit()]. By
default the thread identity and exit status persist after the thread
has terminated until the status is retrieved using pthread_join().
An application should either retrieve this status or arrange for it
to be automatically discarded on thread termination using
pthread_detach() or setting the detach thread attribute.
Mutex Lock
A mutex lock facilitates exclusive access by a thread to a resource.
Only one thread may own a mutex at a time and is thus guaranteed
exclusive access.
Mutex interfaces are described on the pthread_mutex_* man pages.
The pthread_mutexattr_* interfaces may be used to create a mutex
attributes object. Attributes include error checking, recursion and
owner priority. Mutexes are intended to be lightweight and only
owned for brief periods of time.
Condition Variable
A condition variable synchronises threads with an event of interest.
Condition variables allow a thread to wait for an event and be woken
up when the event occurs; the nature of the event is determined by
the application.
Condition variable interfaces are described on the pthread_cond_*
man pages. The pthread_condattr_* interfaces may be used to create
a condition variable attributes object.
Read-Write Lock
A read-write lock facilitates shared access for read and exclusive
access for write by threads to a resource. They are used in
conjunction with resources which are frequently read but
infrequently changed (written).
Read-write lock interfaces are described on the pthread_rwlock_* man
pages. The pthread_rwlockattr_* interfaces may be used to create a
read-write lock attributes object.
Page 2
pthreads(5) pthreads(5)
Semaphore
A semaphore synchronises threads with a counter. Semaphores are not
part of pthreads per se and do not have an associated attributes
object. However anonymous semaphores provide a pshared flag (for
semaphores which are private to the process) which allows pthreads
to optimise access [see sem_init(3C)]. Semaphore interfaces are
described on the sem_* man pages.
Semantics
POSIX threads introduces the following special semantics.
Cancellation
A cancellation request is a request for a thread to terminate. Each
thread specifies whether and when to act on cancellation requests
using its cancelability state and type. A request is made with
pthread_cancel() and the state and type are set with
pthread_setcancelstate() and pthread_setcanceltype(). Termination
handlers may be established to execute code when a thread terminates
for some reason including acting on a cancellation request.
Signals
In the pthread signal model all threads share the signal disposition
[see sigaction(2)] but each thread has its own signal mask of
blocked signals. Signals may be sent to individual threads using
the pthread_kill() interface. Each thread may change its own mask
using pthread_sigmask(). In IRIX, sigprocmask(2) is equivalent to
pthread_sigmask() but a portable pthread application should only use
the latter.
A signal is delivered to at most one thread; it is not broadcast to
all threads.
⊕ When a signal is directed at a process the first eligible thread
is chosen to receive it. An eligible thread is one that does
not have the signal blocked in its signal mask or is waiting in
sigwait(3). If there are no eligible threads then the signal
remains pending on the process until a thread becomes eligible.
This is called asynchronous signal delivery; kill(2) causes this
type of delivery.
⊕ When a signal is directed at a thread then that thread will
receive it. If the signal is blocked then it will remain
pending on the target thread; it will not be delivered to a
different thread. This is called synchronous signal delivery;
exceptions and program faults cause this type of delivery.
⊕ If the action of the signal is to stop, continue or terminate
the recipient then it will act on the process as a whole. It is
not possible to stop, continue or terminate a single thread with
a signal.
Page 3
pthreads(5) pthreads(5)
Notifications
An extension to signal handling for threads is the addition of
SIGEVTHREAD which creates a thread instead of sending a signal as a
means of handling the occurrence of some event [see mq_notify(3C),
aio_read(3) and timer_create(3C)]. Creation of the thread takes
place when the event occurs so care should be taken to avoid any
errors or else the notification may be lost.
Scheduling
When a processor executes instructions on behalf of a user it does
so according to a set of scheduling attributes which are part of a
kernel execution vehicle. Every thread that executes on a processor
or waits in the kernel needs such a vehicle.
POSIX threads makes a distinction between system scope (kernel)
scheduling and process scope (run-time) scheduling. In both scopes
the individual thread scheduling policy and priority values are set
using the interfaces pthread_attr_setschedpolicy(),
pthread_attr_setschedparam(), and pthread_setschedparam().
Scope is defined when a thread is created using
pthread_attr_setscope():
system scope threads are scheduled by the kernel; the scheduling
attributes of the thread and the kernel execution vehicle are the
same. The kernel includes all system scope threads in its
scheduling decisions. These threads run at realtime policy and
priority and may only be created by privileged users.
process scope threads are scheduled by the pthread run-time; the
scheduling attributes of the thread and the kernel execution vehicle
may be different. The run-time makes scheduling decisions based
only on the process scope threads in the host process.
An advantage of system scope is that a thread can get high
performance and deterministic response. A disadvantage is that
kernel resources must be allocated to each thread.
In contrast, process scope threads only require kernel state when
they are executing on a processor or waiting in the kernel. The
run-time scheduler multiplexes process scope threads onto a smaller
number of kernel execution vehicles. This can produce faster
scheduling because no kernel state is involved.
The number of execution vehicles used for process scope threads
depends on application behaviour and system configuration. By
default, the run-time adjusts this number dynamically but the
pthread_setconcurrency() interface gives a strong hint as to the
desired value.
The execution vehicles used for process scope threads share a set of
kernel scheduling attributes which can be changed using the
sched_setscheduler() and sched_setparam() interfaces. These
Page 4
pthreads(5) pthreads(5)
interfaces do not affect system scope thread scheduling. As with
system scope threads changing these scheduling attributes is a
privileged operation.
Thread Data
Pthreads share the address space; stacks, text and data are
accessible by all threads in the process. This means that access to
shared data is simpler than where multiple processes use a shared
memory region which each must map. The cost is the potential for
accidental corruption. Individual thread data is provided using the
notion of a shared set of keys and unique thread values bound to
each key. The pthread_key_create() interface creates a new, shared
key and pthread_setspecific() allows a thread to bind its own value
to a key. Conceptually, the key is an index to an array of values.
The same key used by different threads may retrieve a different
values because each thread has its own array.
Process Management
Some basic UNIX interfaces have particular semantics when called
from a POSIX threads process.
fork(2) creates a new pthread process and follows the usual rules
for inherited state. The new process has a single pthread (the one
which made the call); all other pthreads active prior to fork() are
quietly destroyed and their resources (stacks etc.) reclaimed by the
pthread run-time. A number of issues arise because fork() causes
data to be copied from the parent to the child with no
synchronisation with threads that may be modifying that data. To
allow the application to perform its own synchronisation the
pthread_atfork() interface can register handlers to be processed
when fork() is used. In general operations which are safe to
perform after a fork() are the same as those which are safe to
perform in a signal handler.
exec(2) overlays a new process image on the calling process; all
threads from the old image are destroyed. Thread termination
handlers and thread data destruction [see pthread_cleanup_push()
and pthread_key_create()] are not performed. The new process will
only be a pthread process if the new image is of a pthread process.
exit(2) performs all the usual process clean up operations and then
destroys all threads in the process. Thread termination handlers
and thread data destruction [see pthread_cleanup_push() and
pthread_key_create()] are not performed.
Limitations
With POSIX threads there are some limitations and practices to avoid.
Not enough pthreads
Each pthread process has a resource limit called RLIMITPTHREAD on
the number of threads it can create. The value is inherited by
child processes and may be set using setrlimit(2) or the shell limit
Page 5
pthreads(5) pthreads(5)
and ulimit commands. The default limits can be changed using the
systune(1M) command on the rlimit_pthread_cur and rlimit_pthread_max
variables.
Fatal exceptions
When a thread executes code in the pthread run-time scheduler it
masks signals so that signal handlers always run in a consistent
environment. A side effect of this is that if the thread raises an
exception (for example due to memory corruption) the kernel will
terminate the process. As an aid to debugging such problems the
environment variable PTCORE should be set prior to starting the
application so that a core file will be generated.
Stack overrun
Unlike the default stack in an unthreaded IRIX process, pthread
stacks are limited [see pthread_attr_setstacksize()] and a thread
may overrun its stack. By default pthread stacks have a protected
region at the end of the stack [see pthread_attr_setguardsize()]
that can turn some of these overruns into a protection faults which
is generally preferable to overwriting data.
Dynamic loading
The pthread run-time relies on preempting some calls implemented by
the C run-time (libc). This requirement means that the pthread DSO
cannot safely be dynamically loaded using dlopen(3C) or
sgidladd(3C).
Using sprocs
The sproc(2) model of threading is incompatible with POSIX threads.
Attempts by an sproc process to create pthreads and vice-versa will
be rejected.
MAPLOCAL memory
The POSIX thread memory model requires that memory be available to
all threads. The MAPLOCAL option to mmap(2) is useful only to
sproc processes and should not be used with pthreads.
Dynamic memory allocation
The sbrk(2) call is not thread-safe. It is used by the C run-time
memory allocator, malloc(3C), which is always used by the pthread
run-time. Safe use of sbrk(2) outside of the run-time (for example
by a third party memory allocator) is not therefore possible.
Documentation
Additional on-line documentation about pthreads is available in:
Topics in IRIX Programming: Chapter 13
SpeedShop User's Guide: Chapter 6
SEE ALSO
pthread_*(3P)
Page 6