|THREADS(7)||Standards, Environments, and Macros||THREADS(7)|
threads, pthreads - POSIX pthreads, c11, and illumos threads concepts
gcc -D_REENTRANT [ flag... ] file... [ library... ]
gcc -std=c11 -D_REENTRANT [ flag... ] file... [ library... ]
gcc -D_REENTRANT [ flag... ] file... [ library... ]
A thread is an independent source of execution within a process. Every process is created with a single thread, which calls the main function. A process may have multiple threads, all of which are scheduled independently by the system and may run concurrently. Threads within a process all use the same address space and as a result can access all data in the process; however, each thread is created with its own attributes and its own stack. When a thread is created, it inherits the signal mask of the thread which created it, but it has no pending signals.
All threads of execution have their own, independent life time, though it is ultimately bounded by the life time of the process. If the process terminates for any reason, whether due to a call to exit(3C), the receipt of a fatal signal, or some other reason, then all threads within the process are terminated. Threads may themselves exit and status information of them may be obtained, for more information, see the pthread_detach(3C), pthread_join(3C), and pthread_exit(3C) functions, and their equivalents as described in the tables later on in the manual.
Most hardware platforms do not have any special synchronization for data objects which may be accessed concurrently from multiple threads of execution. To avoid such problems, programs may use atomic operations (see atomic_ops(3C)) and locking primitives, such as mutexes, readers/writer locks, condition variables, and semaphores. Note, that depending on the hardware platform, memory synchronization may be necessary, for more information, see membar_ops(3C).
POSIX, C11, and illumos threads each have their own implementation within libc(3LIB). All 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 environments. C11 threads are an optional part of ISO C11 and may not exist on every ISO C11 platform. POSIX, C11, and illumos threads require different source and include files. See SYNOPSIS.
Most of the POSIX and illumos threading functions have counterparts with each other. POSIX function names, with the exception of the semaphore names, have a "pthread" prefix. Function names for similar POSIX and illumos functions have similar endings. Typically, similar POSIX and illumos functions have the same number and use of arguments.
POSIX pthreads and illumos threads differ in the following ways:
C11 threads are not as functional as either POSIX or illumos threads. C11 threads only support intra-process locking and do not have any form of readers/writer locking or semaphores. In general, POSIX threads will be more portable than C11 threads, all POSIX-compliant systems support pthreads; however, not all C environments support C11 Threads.
In addition to lacking other common synchronization primitives, the ISO/IEC standard for C11 threads does not have rich error semantics. In an effort to not extend the set of error numbers standardized in ISO/IEC C11, none of the routines set errno and instead multiple distinguishable errors, aside from the equivalent to ENOMEM and EBUSY, are all squashed into one. As such, users of the platform are encouraged to use POSIX threads, unless a portability concern dictates otherwise.
The following table compares the POSIX pthreads, C11 threads, and illumos threads functions. When a comparable interface is not available either in POSIX pthreads, C11 threads or illumos threads, a hyphen (-) appears in the column.
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 illumos implement four synchronization mechanisms: mutexes, condition variables, reader/writer locking (optimized frequent-read occasional-write mutex), and semaphores, where as C11 threads only implement two mechanisms: mutexes and condition variables.
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 fork().
illumos supports the following three POSIX scheduling policies:
In addition to the POSIX-specified scheduling policies above, illumos also supports these scheduling policies:
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).
The -mt compiler option compiles and links for multithreaded code. It compiles source files with −D_REENTRANT and augments the set of support libraries properly.
Users of other compilers such as gcc and clang should manually set −D_REENTRANT on the compilation line. There are no other libraries or flags necessary.
See attributes(7) for descriptions of the following attributes:
|ATTRIBUTE TYPE||ATTRIBUTE VALUE|
|MT-Level||MT-Safe, Fork 1-Safe|
Linker and Libraries Guide
|March 27, 2016||OmniOS|