4

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?

Tobias Ritzau
  • 3,327
  • 2
  • 18
  • 29
  • A conforming Posix+pthreads implementation will work correctly if you use pthread mutexes or spin mutexes to synchronise your shared data access. – Kerrek SB Oct 07 '12 at 20:54
  • So what you are saying is that if I use any of locking mechanisms, the memory will also be synced across caches, cores, etc.? Does the various implementations specify that? – Tobias Ritzau Oct 07 '12 at 21:05

2 Answers2

8

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.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
0

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.

Jens Gustedt
  • 76,821
  • 6
  • 102
  • 177
  • So how do you handle it? I mean to run an application on a multi-core system without guarantees on how memory is synchronized is kind of like walking an this ice, isn't it? – Tobias Ritzau Oct 07 '12 at 21:29
  • No. Just follow the rules about locks. – R.. GitHub STOP HELPING ICE Oct 07 '12 at 23:42
  • 2
    I disagree that the specification is too loose. You would think that the experts on the committee know what they are doing, and indeed this is true. The "looseness" is just like other unspecified things in C: so that it can be implemented with performance on all sorts of hardware that is *nothing* like x86. – Zan Lynx Oct 07 '12 at 23:57
  • @ZanLynx, I disagree with you on this particular case of the thread interface. There are several defect reports pending for that part, it is just much below the usual "standards" of that committee. POSIX has an experience of about 15 years on that subject, and the POSIX document reflects that. It is just a bad idea to drop all that experience and to chose basically the interface and documentation of one single software vendor, just because he happens to be member of the committee. – Jens Gustedt Oct 08 '12 at 06:53