Programming with POSIX® Threads

int rwlock_attr_init (rwlock_attr_t *attr); int rwlock_attr_destroy (rwlock_attr_t *attr); int rwlock_attr_getpshared (

const rwlock_attr_t *attr, int *pshared); int rwlock_attr_setpshared (

rwlock_attr_t *attr, int pshared); int rwlock_init (

rwlock_t *lock, const rwlock_attr_t *attr); int rwlock_destroy (rwlock_t *lock); int rwlock_rlock (rwlock_t *lock); int rwlock_timedrlock (rwlock_t *lock,

const struct timespec *timeout); int rwlock_tryrlock (rwlock_t *lock); int rwlock_wlock (rwlock_t *lock); int rwlock_timedwlock (rwlock_t *lock,

const struct timespec *timeout); int rwlock_trywlock (rwlock_t *lock); int rwlock_unlock (rwlock_t *lock);

Spinlocks:

int spin_init (spinlock_t *lock);

int spin_destroy (spinlock_t *lock);

int spin_lock (spinlock_t *lock);

int spin_trylock (spinlock_t *lock);

int spin_unlock (spinlock_t *lock);

int pthread_spin_init (pthread_spinlock_t *lock);

int pthread_spin_destroy (pthread_spinlock_t *lock);

int pthread_spin_lock (pthread_spinlock_t *lock);

int pthread_spin_trylock (pthread_spinlock_t *lock);

int pthread_spin_unlock (pthread_spinlock_t *lock);

Thread abort:

int pthread_abort (pthread_t thread);

The same POSIX working group that developed POSIX. lb and Pthreads has developed a new set of extensions for realtime and threaded programming. Most of the extensions relevant to threads (and to this book) are the result of proposals developed by the POSIX 1003.14 profile group, which specialized in "tuning" the existing POSIX standards for multiprocessor systems.

POSIX. lj adds some thread synchronization mechanisms that have been common in a wide range of multiprocessor and thread programming, but that had been omitted from the original Pthreads standard. Barriers and spinlocks are primarily useful for flne-grained parallelism, for example, in systems that automatically

generate parallel code from program loops. Read/write locks are useful in shared data algorithms where many threads are allowed to read simultaneously, but only one thread can be allowed to update data.

10.2.1 Barriers

"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.)

10.2.2 Read/write locks

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.)

*The POSIX working group is considering the possibility of adapting the XSH5 read/write lock definition and abandoning the original POSIX.1j names, but the decision hasn't yet been made.

10.2.3 Spinlocks

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.