threads(5) Standards, Environments, and Macros threads(5)
threads, pthreads - POSIX pthreads and Solaris threads concepts
cc -mt [ flag... ] file... [ -lrt library... ]
cc -mt [ flag... ] file... [ library... ]
POSIX and Solaris threads each have their own implementation within libc(3LIB). Both implementations are interoperable, their functionality
similar, and can be used within the same application. Only POSIX threads are guaranteed to be fully portable to other POSIX-compliant envi-
ronments. POSIX and Solaris threads require different source, include files and linking libraries. See SYNOPSIS.
Most of the POSIX and Solaris threading functions have counterparts with each other. POSIX function names, with the exception of the sema-
phore names, have a "pthread" prefix. Function names for similar POSIX and Solaris functions have similar endings. Typically, similar POSIX
and Solaris functions have the same number and use of arguments.
POSIX pthreads and Solaris threads differ in the following ways:
o POSIX threads are more portable.
o POSIX threads establish characteristics for each thread according to configurable attribute objects.
o POSIX pthreads implement thread cancellation.
o POSIX pthreads enforce scheduling algorithms.
o POSIX pthreads allow for clean-up handlers for fork(2) calls.
o Solaris threads can be suspended and continued.
o Solaris threads implement daemon threads, for whose demise the process does not wait.
The following table compares the POSIX pthreads and Solaris threads functions. When a comparable interface is not available either in POSIX
pthreads or Solaris threads, a hyphen (-) appears in the column.
Functions Related to Creation
Functions Related to Exit
Functions Related to Thread Specific Data
Functions Related to Signals
Functions Related to IDs
Functions Related to Scheduling
Functions Related to Cancellation
Functions Related to Mutexes
Functions Related to Condition Variables
Functions Related to Reader/Writer Locking
Functions Related to Semaphores
Functions Related to fork() Clean Up
Functions Related to Limits
Functions Related to Debugging
Multithreaded behavior is asynchronous, and therefore, optimized for concurrent and parallel processing. As threads, always from within
the same process and sometimes from multiple processes, share global data with each other, they are not guaranteed exclusive access to the
shared data at any point in time. Securing mutually exclusive access to shared data requires synchronization among the threads. Both POSIX
and Solaris implement four synchronization mechanisms: mutexes, condition variables, reader/writer locking (optimized frequent-read occa-
sional-write mutex), and semaphores.
Synchronizing multiple threads diminishes their concurrency. The coarser the grain of synchronization, that is, the larger the block of
code that is locked, the lesser the concurrency.
If a threads program calls fork(2), it implicitly calls fork1(2), which replicates only the calling thread. Should there be any outstanding
mutexes throughout the process, the application should call pthread_atfork(3C) to wait for and acquire those mutexes prior to calling
Solaris supports the following three POSIX scheduling policies:
SCHED_OTHER Traditional Timesharing scheduling policy. It is based on the timesharing (TS) scheduling class.
SCHED_FIFO First-In-First-Out scheduling policy. Threads scheduled to this policy, if not preempted by a higher priority, will proceed
until completion. Such threads are in real-time (RT) scheduling class. The calling process must have a effective user ID of
SCHED_RR Round-Robin scheduling policy. Threads scheduled to this policy, if not preempted by a higher priority, will execute for a
time period determined by the system. Such threads are in real-time (RT) scheduling class and the calling process must have
a effective user ID of 0.
In addition to the POSIX-specified scheduling policies above, Solaris also supports these scheduling policies:
SCHED_IA Threads are scheduled according to the Inter-Active Class (IA) policy as described in priocntl(2).
SCHED_FSS Threads are scheduled according to the Fair-Share Class (FSS) policy as described in priocntl(2).
SCHED_FX Threads are scheduled according to the Fixed-Priority Class (FX) policy as described in priocntl(2).
Only scheduling policy supported is SCHED_OTHER, which is timesharing, based on the TS scheduling class.
In a multithreaded application, EINTR can be returned from blocking system calls when another thread calls forkall(2).
-mt compiler option
The -mt compiler option compiles and links for multithreaded code. It compiles source files with -D_REENTRANT and augments the set of sup-
port libraries properly.
See attributes(5) for descriptions of the following attributes:
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|MT-Level |MT-Safe, Fork 1-Safe |
crle(1), fork(2), priocntl(2), libpthread(3LIB), librt(3LIB), libthread(3LIB), pthread_atfork(3C), pthread_create(3C), attributes(5), stan-
Linker and Libraries Guide
SunOS 5.11 11 Nov 2008 threads(5)