admin 管理员组文章数量: 1086019
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.
本文标签： multithreadingCan pthreadbarriert be used across multiple processes with shared memoryStack Overflow
版权声明：本文标题：multithreading - Can pthread_barrier_t be used across multiple processes with shared memory? - Stack Overflow 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.roclinux.cn/p/1743984207a2513569.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论