Some of the features that are options in the Pthreads standard are required by XSH5. If your code relies on these Pthreads options, it will work on any system conforming to XSH5:

Several additional Pthreads options are “bundled” into the XSH5 realtime threads option group. If your system conforms to XSH5 and supports the _XOPEN_REALTIME_THREADS option, then these Pthreads options are also supported:

The DCE threads package provided an extension that allowed the programmer to specify the “kind” of mutex to be created. DCE threads supplied fast, recursive, and nonrecursive mutex kinds. The XSH5 specification changes the attribute name from “kind” to “type,” renames fast to default, renames nonrecursive to errorcheck, and adds a new type, normal (Table 10.1).

A normal mutex is not allowed to detect deadlock errors—that is, a thread will hang if it tries to lock a normal mutex that it already owns. The default mutex type, like the DCE fast mutex,^[*] provides implementation-defined error checking. That is, default may be mapped to one of the other standard types or may be something entirely different.

As an application developer, you can use any of the mutex types almost interchangeably as long as your code does not depend on the implementation to detect (or fail to detect) any particular errors. Never write code that counts on an implementation failing to detect any error. Do not lock a mutex in one thread and unlock it in another thread, for example, even if you are sure that the error won’t be reported—use a semaphore instead, which has no “ownership” semantics.

All mutexes, regardless of type, are created using pthread_mutex_init, destroyed using pthread_mutex_destroy, and manipulated using pthread_mutex_lock, pthread_mutex_unlock, and pthread_mutex_trylock.

Normal mutexes will usually be the fastest implementation possible for the machine, but will provide the least error checking.

Recursive mutexes are primarily useful for converting old code where it is difficult to establish clear boundaries of synchronization, for example, when you must call a function with a mutex locked and the function you call—or some function it calls—may need to lock the same mutex. I have never seen a situation where recursive mutexes were required to solve a problem, but I have seen many cases where the alternate (and usually “better”) solutions were impractical. Such situations frequently lead developers to create recursive mutexes, and it makes more sense to have a single implementation available to everyone. (But your code will usually be easier to follow, and perform better, if you avoid recursive mutexes.)

Errorcheck mutexes were devised as a debugging tool, although less intrusive debugging tools (where available) can be more powerful. To use errorcheck mutexes you must recompile code to turn the debugging feature on and off. It is far more useful to have an external option to force all mutexes to record debugging data. You may want to use errorcheck mutexes in final “production” code, of course, to detect serious problems early, but be aware that errorcheck mutexes will almost always be much slower than normal mutexes due to the extra state and checking.

Default mutexes allow each implementation to provide the mutex semantics the vendor feels will be most useful to the target audience. It may be useful to make errorcheck mutexes the default, for example, to improve the threaded debugging environment of a system. Or the vendor may choose to make normal mutexes the default to give most programs the benefit of any extra speed.

int pthread_mutexattr_gettype (
        const pthread_mutexattr_t      *attr,
        int                            *type);

int pthread_mutexattr_settype (
        pthread_mutexattr_t              *attr,
        int                              type);

When you use Pthreads implementations that schedule user threads onto some smaller set of kernel entities (see Section 5.6.3), it may be possible to have ready user threads while all kernel entities allocated to the process are busy. Some implementations, for example, “lock” a kernel entity to a user thread that blocks in the kernel, until the blocking condition, for example an I/O request, is completed. The system will create some reasonable number of kernel execution entities for the process, but eventually the pool of kernel entities may become exhausted. The process may be left with threads capable of performing useful work for the application, but no way to schedule them.

The pthread_setconcurrency function addresses this limitation by allowing the application to ask for more kernel entities. If the application designer realizes that 10 out of 15 threads may at any time become blocked in the kernel, and it is important for those other 5 threads to be able to continue processing, then the application may request that the kernel supply 15 kernel entities. If it is important that at least 1 of those 5 continue, but not that all continue, then the application could request the more conservative number of 11 kernel entities. Or if it is OK for all threads to block once in a while, but not often, and you know that only rarely will more than 6 threads block at any time, the application could request 7 kernel entities.

The pthread_setconcurrency function is a hint, and implementations may ignore it or modify the advice. You may use it freely on any system that conforms to the UNIX98 brand, but many systems will do nothing more than set a value that is returned by pthread_getconcurrency. On Digital UNIX, for example, there is no need to set a fixed concurrency level, because the kernel mode and user mode schedulers cooperate to ensure that ready user threads cannot be prevented from running by other threads blocked in the kernel.

int pthread_getconcurrency (void);

int pthread_setconcurrency (int new_level);

Guard size comes from DCE threads. Most thread implementations add to the thread’s stack a “guard” region, a page or more of protected memory. This protected page is a safety zone, to prevent a stack overflow in one thread from corrupting another thread’s stack. There are two good reasons for wanting to control a thread’s guard size:

int pthread_attr_getguardsize (
        const pthread_attr_t     *attr,
        size_t                   *guardsize);

int pthread_attr_setguardsize (
        pthread_attr_t           *attr,
        size_t                   guardsize);

Many high-performance systems, such as database engines, use threads, at least in part, to gain performance through parallel I/O. Unfortunately, Pthreads doesn’t directly support parallel I/O. That is, two threads can independently issue I/O operations for files, or even for the same file, but the POSIX file I/O model places some restrictions on the level of parallelism.

One bottleneck is that the current file position is an attribute of the file descriptor. To read or write data from or to a specific position within a file, a thread must call lseek to seek to the proper byte offset in the file, and then read or write. If more than one thread does this at the same time, the first thread might seek, and then the second thread seek to a different place before the first thread can issue the read or write operation.

The X/Open pread and pwrite functions offer a solution, by making the seek and read or write combination atomic. Threads can issue pread or pwrite operations in parallel, and, in principle, the system can process those I/O requests completely in parallel without locking the file descriptor.

size_t pread (
        int                  fildes,
        void                 *buf,
        size_t               nbyte,
        off_t                offset);

size_t pwrite (
        int                  fildes,
        const void           *buf,
        size_t               nbyte,
        off_t                offset);

Most UNIX systems support a substantial number of interfaces that do not come from POSIX. The select and poll interfaces, for example, should be deferred cancellation points. Pthreads did not require these functions to be cancellation points, however, because they do not exist within POSIX.1.

The select and poll functions, however, along with many others, exist in X/Open. The XSH5 standard includes an expanded list of cancellation points covering X/Open interfaces.

Additional functions that must be cancellation points in XSH5:

getmsg          pread          sigpause
getpmsg         putmsg         usleep
lockf           putpmsg        wait3
msgrcv          pwrite         waitid
msgsnd          readv          writev
poll            select

Additional functions that may be cancellation points in XSH5:

catclose      fsetpos      popen
catgets       ftello       pututxline
catopen       ftw          putw
closelog      fwprintf     putwc
dbm_close     fwscanf      putwchar
dbm_delete    getgrent     readdir_r
dbm_fetch     getpwent     seekdir
dbm_nextkey   getutxent    semop
dbm_open      getutxid     setgrent
dbm_store     getutxline   setpwent
dlclose       getw         setutxent
dlopen        getwc        syslog
endgrent      getwchar     ungetwc
endpwent      iconv_close  vfprintf
endutxent     iconv_open   vfwprintf
fgetwc        ioctl        vprintf
fgetws        mkstemp      vwprintf
fputwc        nftw         wprintf
fputws        openlog      wscanf
fseeko        pclose

“Barriers” are a form of synchronization most commonly used in parallel decomposition of loops. They’re almost never used except in code designed to run only on multiprocessor systems. A barrier is a “meeting place” for a group of associated threads, where each will wait until all have reached the barrier. When the last one waits on the barrier, all the participating threads are released.

See Section 7.1.1 for details of barrier behavior and for an example showing how to implement a barrier using standard Pthreads synchronization. (Note that the behavior of this example is not precisely the same as that proposed by POSIX.1j.)

A read/write lock (also sometimes known as “reader/writer lock”) allows one thread to exclusively lock some shared data to write or modify that data, but also allows multiple threads to simultaneously lock the data for read access. UNIX98 specifies “read/write locks” very similar to POSIX.1j reader/writer locks. Although X/Open intends that the two specifications will be functionally identical, the names are different to avoid conflict should the POSIX standard change before approval.^[*]

If your code relies on a data structure that is frequently referenced, but only occasionally updated, you should consider using a read/write lock rather than a mutex to access that data. Most threads will be able to read the data without waiting; they’ll need to block only when some thread is in the process of modifying the data. (Similarly, a thread that desires to write the data will be blocked if any threads are reading the data.)

See Section 7.1.2 for details of read/write lock behavior and for an example showing how to implement a read/write lock using standard Pthreads synchronization. (Note that the behavior of this example is not precisely the same as that proposed by POSIX.1j.)

Spinlocks are much like mutexes. There’s been a lot of discussion about whether it even makes sense to standardize on a spinlock interface—since POSIX specifies only a source level API, there’s very little POSIX.1j says about them that distinguishes them from mutexes. The essential idea is that a spinlock is the most primitive and fastest synchronization mechanism available on a given hardware architecture. On some systems, that may be a single “test and set” instruction—on others, it may be a substantial sequence of “load locked, test, store conditional, memory barrier” instructions.

The critical distinction is that a thread trying to lock a spinlock does not necessarily block when the spinlock is already held by another thread. The intent is that the thread will “spin,” retrying the lock rapidly until it succeeds in locking the spinlock. (This is one of the “iffy” spots—on a uniprocessor it had better block, or it’ll do nothing but spin out the rest of its timeslice . . . or spin to eternity if it isn’t timesliced.)

Spinlocks are great for fine-grained parallelism, when the code is intended to run only on a multiprocessor, carefully tuned to hold the spinlock for only a few instructions, and getting ultimate performance is more important than sharing the system resources cordially with other processes. To be effective, a spinlock must never be locked for as long as it takes to “context switch” from one thread to another. If it does take as long or longer, you’ll get better overall performance by blocking and allowing some other thread to do useful work.

POSIX.1j contains two sets of spinlock functions: one set with a spin_ prefix, which allows spinlock synchronization between processes; and the other set with a pthread_ prefix, allowing spinlock synchronization between threads within a process. This, you will notice, is very different from the model used for mutexes, condition variables, and read/write locks, where the same functions were used and the pshared attribute specifies whether the resulting synchronization object can be shared between processes.

The rationale for this is that spinlocks are intended to be very fast, and should not be subject to any possible overhead as a result of needing to decide, at run time, how to behave. It is, in fact, unlikely that the implementation of spin_lock and pthread_spin_lock will differ on most systems, but the standard allows them to be different.

Pthreads condition variables support only “absolute time” timeouts. That is, the thread specifies that it is willing to wait until “Jan 1 00:00:00 GMT 2001,” rather than being able to specify that it wants to wait for “1 hour, 10 minutes.” The reason for this is that a condition variable wait is subject to wakeups for various reasons that are beyond your control or not easy to control. When you wake early from a “1 hour, 10 minute” wait it is difficult to determine how much of that time is left. But when you wake early from the absolute wait, your target time is still “Jan 1 00:00:00 GMT 2001.” (The reasons for early wakeup are discussed in Section 3.3.2.)

Despite all this excellent reasoning, “relative time” waits are useful. One important advantage is that absolute system time is subject to external changes. It might be modified to correct for an inaccurate clock chip, or brought up-to-date with a network time server, or adjusted for any number of other reasons. Both relative time waits and absolute time waits remain correct across that adjustment, but a relative time wait expressed as if it were an absolute time wait cannot. That is, when you want to wait for “1 hour, 10 minutes,” but the best you can do is add that interval to the current clock and wait until that clock time, the system can’t adjust the absolute timeout for you when the system time is changed.

POSIX.1j addresses this issue as part of a substantial and pervasive “cleanup” of POSIX time services. The standard (building on top of POSIX.1b, which introduced the realtime clock functions, and the CLOCK_REALTIME clock) introduces a new system clock called CLOCK_MONOTONIC. This new clock isn’t a “relative timer” in the traditional sense, but it is never decreased, and it is never modified by date or time changes on the system. It increases at a constant rate. A “relative time” wait is nothing more than taking the current absolute value of the CLOCK_MONOTONIC clock, adding some fixed offset (4200 seconds for a wait of 1 hour and 10 minutes), and waiting until that value of the clock is reached.

This is accomplished by adding the condition variable attribute clock. You set the clock attribute in a condition variable attributes object using pthread_condattr_setclock and request the current value by calling pthread_condattr_getclock. The default value is CLOCK_MONOTONIC, on the assumption that most condition waits are intervals.

While this assumption may be incorrect, and it may seem to be an incompatible change from Pthreads (and it is, in a way), this was swept under the rug due to the fact that the timed condition wait function suffered from a problem that POSIX.1j found to be extremely common through the existing body of POSIX standards. “Time” in general was only very loosely defined. A timed condition wait, for example, does not say precisely what the timeout argument means. Only that “an error is returned if the absolute time specified by abstime passes (that is, system time equals or exceeds abstime).” The intent is clear—but there are no specific implementation or usage directives. One might reasonably assume that one should acquire the current time using clock_gettime (CLOCK_REALTIME,&now), as suggested in the associated rationale. However, POSIX “rationale” is little more than historical commentary, and is not part of the formal standard. Furthermore, clock_gettime is a part of the optional _POSIX_TIMERS subset of POSIX.1b, and therefore may not exist on many systems supporting threads.

POSIX.1j is attempting to “rationalize” all of these loose ends, at least for systems that implement the eventual POSIX.1j standard. Of course, the CLOCK_MONOTONIC feature is under an option of its own, and additionally relies on the _POSIX_TIMERS option, so it isn’t a cure-all. In the absence of these options, there is no clock attribute, and no way to be sure of relative timeout behavior—or even completely portable behavior.

The pthread_abort function is essentially fail-safe cancellation. It is used only when you want to be sure the thread will terminate immediately. The dangerous aspect of pthread_abort is that the thread does not run cleanup handlers or have any other opportunity to clean up after itself. That is, if the target thread has a mutex locked, the thread will terminate with the mutex still locked. Because you cannot unlock the mutex from another thread, the application must be prepared to abandon that mutex entirely. Further, it means that any other threads that might be waiting for the abandoned mutex will continue to wait for the mutex forever unless they are also terminated by calling pthread_abort.

In general, real applications cannot recover from aborting a thread, and you should never, ever, use pthread_abort. However, for a certain class of applications this capability is required. Imagine, for example, a realtime embedded control system that cannot shut down and must run reliably across any transient failure in some algorithm. Should a thread encounter a rare boundary condition bug, and hang, the application must recover.

In such a system, all wait operations use timeouts, because realtime response is critical. Should one thread detect that something hasn’t happened in a reasonable time, for example, a navigational thread hasn’t received sensor input, it will notify an “error manager.” If the error manager cannot determine why the thread monitoring the sensor hasn’t responded, it will try to recover. It may attempt to cancel the sensor thread to achieve a safe shutdown, but if the sensor thread fails to respond to the cancel in a reasonable time, the application must continue anyway. The error manager would then abort the sensor thread, analyze and correct any data structures it might have corrupted, create and advertise new mutexes if necessary, and create a new sensor thread.