如何解决多重处理：sharedctypesRawArray，RawValue如何在内部工作，它们如何与SharedMemory和相关问题进行比较
我一直在阅读并发以及SysV和POSIX风格的共享内存，尤其是Python的多处理程序包。现在，我有一些问题要问，到目前为止，我的Google-fu在哪里都还没有到我那里：
第一季度据我从this issue in the Python bugtracker所了解，最近推出的multiprocessing.shared_memory.SharedMemory使用POSIX命名为共享内存。但是，当涉及到RawArray中定义的RawValue和multiprocessing.sharedctypes之类的类型时，Python文档还有很多不足之处。它们是如何在内部实现的？
Q2 是RawArray('B')与multiprocessing.shared_memory.SharedMemory实例之间唯一的实际区别，即后者具有名称，并且也可以从不相关的对象（可能是非-Python）进程？他们的表现可比吗？
Q3 如何在Python中实现多处理锁？他们还不需要使用某种共享内存吗？ docs说：
注意
此软件包的某些功能需要有效的共享 主机操作系统上的信号量实现。没有一个 multiprocessing.synchronize模块将被禁用，并尝试 导入它会导致ImportError。有关详情，请参见bpo-3770 其他信息。
（请注意multiprocessing.Lock实际上源自multiprocessing.synchronize.Lock。）现在，根据链接的问题bpo-3770，Lock使用libc的shm_open()来创建命名信号量。这类似于SharedMemory的工作方式吗？
更新：根据源代码，尤其是以下行：Link 1，link 2（谢谢，bnaecker！），在非Windows系统上{ {1}和RawArray只是使用一个临时文件（至少在Linux上）实现的，该文件放置在一个不受存储支持的目录中，即RawValue。这似乎与POSIX共享存储（即/dev/shm）的工作方式非常相似。因此，我想我将问题Q1替换为以下问题：为什么首先引入SharedMemory，然后如果shared_memory如此相似？开头提到的issue提到了性能原因，但我不知道性能差异（至少在Linux上）应该来自哪里？
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
