C++ 如果在共享内存中，pthread 互斥体是否可以跨线程工作？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2389353/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Do pthread mutexes work across threads if in shared memory?
提问by anon
I found this: Fast interprocess synchronization method
我发现了这个： 快速进程间同步方法
I used to believe that a pthread mutex can only be shared between two threads in the same address space.
我曾经认为 pthread 互斥只能在同一地址空间中的两个线程之间共享。
The question / answers there seems to imply:
那里的问题/答案似乎暗示：
If I have two separate proceses A & B. They have a shared memory region M. I can put a pThread mutex in M, lock in A, lock in B, unlock in A; and B will no longer block on the mutex. Is this correct? Can pThread mutexes be shared in two separate processes?
如果我有两个单独的进程 A 和 B。它们有一个共享内存区域 M。我可以在 M 中放置一个 pThread 互斥锁，在 A 中锁定，在 B 中锁定，在 A 中解锁；并且 B 将不再阻塞互斥锁。这样对吗？pThread 互斥体可以在两个单独的进程中共享吗？
Edit: I'm using C++, on MacOSX.
编辑：我在 MacOSX 上使用 C++。
回答by Steve Jessop
You need to tell the mutex to be process-shared when it's inited:
您需要在启动时告诉互斥锁是进程共享的：
http://www.opengroup.org/onlinepubs/007908775/xsh/pthread_mutexattr_setpshared.html
http://www.opengroup.org/onlinepubs/007908775/xsh/pthread_mutexattr_setpshared.html
Note in particular, "The default value of the attribute is PTHREAD_PROCESS_PRIVATE", meaning that accessing it from different processes is undefined behaviour.
特别注意，“属性的默认值是 PTHREAD_PROCESS_PRIVATE”，这意味着从不同进程访问它是未定义的行为。
回答by Void
If your C/pthread library is conforming, you should be able to tell if it supports mutexes shared across multiple process by checking if the _POSIX_THREAD_PROCESS_SHAREDfeature test macro is defined to a value other than -1or by querying the system configuration at run-time using sysconf(_SC_THREAD_PROCESS_SHARED)if that feature test macro is undefined.
如果您的 C/pthread 库符合要求，您应该能够通过检查_POSIX_THREAD_PROCESS_SHARED功能测试宏是否定义为其他值-1或通过在运行时查询系统配置使用sysconf(_SC_THREAD_PROCESS_SHARED)if来判断它是否支持跨多个进程共享的互斥锁功能测试宏未定义。
EDIT: As Steve pointed out, you'll need to explicitly configure the mutex for sharing across processes assuming the platform supports that feature as I described above.
编辑：正如史蒂夫指出的那样，假设平台支持上述功能，您需要显式配置互斥锁以跨进程共享。
回答by Sniggerfardimungus
I was concerned that there might be a condition where a mutex in shared memory might fail to behave properly, so I did some digging and came up with some documents which treat the issue like a no-brainer:
我担心可能存在共享内存中的互斥锁可能无法正常运行的情况，因此我进行了一些挖掘并提出了一些文档，这些文档将这个问题视为轻而易举的：
https://computing.llnl.gov/tutorials/pthreads/
https://computing.llnl.gov/tutorials/pthreads/
Further digging, however, showed that older versions of glibc suffered issues in shared memory mutexes: (This is an ancient change, but it illustrates the point.)
然而，进一步的挖掘表明，旧版本的 glibc 在共享内存互斥锁方面存在问题：（这是一个古老的变化，但它说明了这一点。）
in linuxthreads/mutex.c
int __pthread_mutexattr_setpshared(...) {
/* For now it is not possible to shared a conditional variable. */
if (pshared != PTHREAD_PROCESS_PRIVATE)
return ENOSYS;
}
Without more detail on what implementation of pthread you're using, it's difficult to say whether you're safe or not.
如果没有关于您正在使用的 pthread 实现的更多细节，很难说您是否安全。
My cause for concern is that many implementations (and some entire languages, like perl, python, and ruby) have a global lock object that manages access to shared objects. That object would not be shared between processes and therefore, while your mutexes would probably work most of the time, you might find yourself having two processes simultaneously manipulating the mutex at the same time.
我担心的原因是许多实现（以及一些完整的语言，如 perl、python 和 ruby）都有一个全局锁对象来管理对共享对象的访问。该对象不会在进程之间共享，因此，虽然您的互斥锁可能大部分时间都在工作，但您可能会发现自己有两个进程同时操作互斥锁。
I know that this flies in the face of the definition of a mutex but it is possible:
我知道这与互斥锁的定义背道而驰，但这是可能的：
If two threads are operating at the same time in different processes, it implies that they are on different cores. Both acquire their global lock object and go to manipulate the mutex in shared memory. If the pthread implementation forces the update of the mutex through the caches, both threads could end up updating at the same time, both thinking they hold the mutex. This is just a possible failure vector that comes to mind. There could be any number of others. What are the specifics of your situation - OS, pthreads version, etc.?
如果两个线程同时在不同的进程中运行，则意味着它们在不同的内核上。两者都获取他们的全局锁对象并去操作共享内存中的互斥锁。如果 pthread 实现强制通过缓存更新互斥锁，则两个线程可能最终同时更新，都认为它们持有互斥锁。这只是想到的一个可能的故障向量。可以有任意数量的其他人。您的具体情况是什么 - 操作系统、pthreads 版本等？
