多处理：sharedctypes（RawArray、RawValue）内部如何工作，它们与 SharedMemory 相比如何以及相关问题

Question

我一直在阅读并发性以及 SysV 和 POSIX 风格的共享内存，特别是 Python 的多处理包。现在我有几个问题，到目前为止我的 Google-fu 还没有找到答案：

\n

Q1据我从Python bugtracker 中的这个问题了解到，最近引入的multiprocessing.shared_memory.SharedMemory使用 POSIX 命名的共享内存。然而，当涉及到RawArray和RawValue中定义的类型时multiprocessing.sharedctypes，Python 文档还有很多不足之处。它们在内部是如何实施的？

\n

Q2例如， aRawArray(\'B\')和 a 的实例之间唯一的实际区别是multiprocessing.shared_memory.SharedMemory后者有名称并且也可以从不相关（可能是非 Python）的进程访问吗？他们的表现有可比性吗？

\n

Q3 Python 中多处理锁到底是如何实现的？难道他们不需要使用某种共享内存吗？文档说：

\n

\n

笔记

\n

此包\xe2\x80\x99s 的某些功能需要主机操作系统上有效的共享\nsemaphore 实现。如果没有，multiprocessing.synchronize 模块将被禁用，并且尝试导入它会导致导入错误。请参阅bpo-3770了解\n更多信息。

\n

\n

（请注意，multiprocessing.Lock实际上源自multiprocessing.synchronize.Lock。）现在根据链接的问题bpo-3770，Lock使用 libc\'sshm_open()创建一个命名信号量。这与工作原理相似吗SharedMemory？

\n

更新：根据源代码 \xe2\x80\x93 特别是，这些行：Link 1，link 2（谢谢你，bnaecker！），非 Windows 系统上的 \xe2\x80\x93 RawArray，RawValue只是使用临时实现文件（至少在 Linux 上）放置在不受存储支持的目录中，即/dev/shm. 这看起来与 POSIX 共享存储的SharedMemory工作方式非常相似。所以我想我应该用以下问题替换我的问题 Q1：为什么shared_memory首先引入 ifRawArray如此相似？上述问题从一开始就提到了性能原因，但我不明白这种性能差异（至少在 Linux 上）应该来自哪里？

\n