I'm working on a C++ application that launches multiple processes. All of them load the same executable and share a memory region using shm_open + mmap.
In that shared memory, we store a pthread_barrier_t object, and each process calls pthread_barrier_wait() on it.
This setup has been working reliably in our production system for quite a while.
Recently, I came across information stating that pthread_barrier_t is only designed for synchronization between threads in the same process — and that cross-process use is not officially supported by POSIX.
I want to better understand the situation:
Is using pthread_barrier_t between processes officially unsupported or undefined?
Why might it still appear to work in practice?
What are the risks of continuing to use it this way?
What is the proper, portable way to implement a barrier across multiple processes using pthread primitives or alternatives?
Any insights or references would be appreciated.
I'm working on a C++ application that launches multiple processes. All of them load the same executable and share a memory region using shm_open + mmap.
In that shared memory, we store a pthread_barrier_t object, and each process calls pthread_barrier_wait() on it.
This setup has been working reliably in our production system for quite a while.
Recently, I came across information stating that pthread_barrier_t is only designed for synchronization between threads in the same process — and that cross-process use is not officially supported by POSIX.
I want to better understand the situation:
Is using pthread_barrier_t between processes officially unsupported or undefined?
Why might it still appear to work in practice?
What are the risks of continuing to use it this way?
What is the proper, portable way to implement a barrier across multiple processes using pthread primitives or alternatives?
Any insights or references would be appreciated.
Share Improve this question asked Mar 30 at 15:19 Ilan NoyIlan Noy 11 Answer
Reset to default 2The existence of the pthread_barrierattr_setpshared function certainly suggests that it can work, but you need to explicitly call this (and set it to PTHREAD_PROCESS_SHARED) to be portable.
There's a brief discussion here which confirms that this is intended to work with mmap.
Is using pthread_barrier_t between processes officially unsupported or undefined?
No, it is officially supported in the spec, and described in the (free, searchable) documentation.
You can confirm locally by running man pthread_barrierattr_setpshared.
Why might it still appear to work in practice?
Because it does actually work in practice.
If it's working despite not having set the attribute correctly, it just means your host implementation doesn't do anything different for private & shared, but depending on this is non-portable.
What are the risks of continuing to use it this way?
Only the lack of portability unless you set the process-shared attribute explicitly.
What is the proper, portable way to implement a barrier across multiple processes using pthread primitives or alternatives?
Just set the process-shared attribute and carry on as before.
... that cross-process use is not officially supported by POSIX.
Citation please. It'd be good to know where this bad information is coming from.