Memory model spec in pthreads

问题:

Are there any guarantees on when a memory write in one thread becomes visible in other threads using pthreads?

Comparing to Java, the Java language spec has a section that specifies the interaction of locks and memory that makes it possible to write portable multi-threaded Java code.

Is there a corresponding pthreads spec?

Sure, you can always go and make shared data volatile, but that is not what I'm after.

If this is platform dependent, is there a de facto standard? Or should another threading library be used?

回答1:

POSIX specifies the memory model in 4.11 Memory Synchronization:

Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thread of control can read or modify a memory location while another thread of control may be modifying it. Such access is restricted using functions that synchronize thread execution and also synchronize memory with respect to other threads. The following functions synchronize memory with respect to other threads:

• fork()
• pthread_barrier_wait()
• pthread_cond_broadcast()
• pthread_cond_signal()
• pthread_cond_timedwait()
• pthread_cond_wait()
• pthread_create()
• pthread_join()
• pthread_mutex_lock()
• pthread_mutex_timedlock()
• pthread_mutex_trylock()
• pthread_mutex_unlock()
• pthread_spin_lock()
• pthread_spin_trylock()
• pthread_spin_unlock()
• pthread_rwlock_rdlock()
• pthread_rwlock_timedrdlock()
• pthread_rwlock_timedwrlock()
• pthread_rwlock_tryrdlock()
• pthread_rwlock_trywrlock()
• pthread_rwlock_unlock()
• pthread_rwlock_wrlock()
• sem_post()
• sem_timedwait()
• sem_trywait()
• sem_wait()
• semctl()
• semop()
• wait()
• waitpid()

The pthread_once() function shall synchronize memory for the first call in each thread for a given pthread_once_t object.

The pthread_mutex_lock() function need not synchronize memory if the mutex type if PTHREAD_MUTEX_RECURSIVE and the calling thread already owns the mutex. The pthread_mutex_unlock() function need not synchronize memory if the mutex type is PTHREAD_MUTEX_RECURSIVE and the mutex has a lock count greater than one.

Unless explicitly stated otherwise, if one of the above functions returns an error, it is unspecified whether the invocation causes memory to be synchronized.

Applications may allow more than one thread of control to read a memory location simultaneously.

回答2:

I am not aware that POSIX threads give such guarantees. They don't have a model for atomic access to thread-shared objects. If it'd be for POSIX threads, the only guarantees that you can have for visibility of modifications is using some kind of lock.

Modern C, C11, (and probably also C++11) has a model for this kind of questions. It has threads and atomics (fences and all that stuff) that give you exact rules when you may assume that a modification done by one thread is visible by another.

The thread interface of C11 is a cooked-down version of POSIX threads, with less functionality. Unfortunately, the specification for the semantics of that thread interface is yet much to loose, basically the semantics are missing in many places. But a combination of C11 interfaces and POSIX thread semantics can give you a good view of how things work in modern systems.

Edit: So if you want to have guarantees for memory synchronization use either the lock interfaces that POSIX provides or go for atomic operations. All modern compilers have extensions that provide these, gcc and family (icc, opencc, clang) have e.g the series of __sync... builtins. Clang it its newest version also already has support of the new C11 _Atomic feature. There are also wrappers available that give you interfaces for the other compilers that come close to _Atomic.