是否有理由在multiprocessing.Lock上使用multiprocessing.Lock？

Question

如果一个软件项目支持已支持多处理的Python版本，那么是否有理由在multiprocessing.Lock上使用multiprocessing.Lock？multiprocessing锁是否也是线程安全的？

因此，是否有理由使用来自threading的同步原语，这些原语也在multiprocessing中。

Answer 1

由于缺乏对共享信号量的处理，线程模块的同步原语比多处理更轻和更快，等等。如果您使用线程，请使用线程的锁。进程应该使用多进程的锁。

Answer 2

我希望多线程同步原语会更快，因为它们可以很容易地使用共享内存区域。但我想你得做速度测试才能确定。此外，您可能有副作用，这是非常不想要的(在文档中未指定)。

例如，一个进程级锁可以很好地阻塞进程的所有线程.如果没有，释放锁可能不会唤醒进程的线程。

简而言之，如果您希望代码确实工作，那么如果您使用线程，则应该使用线程同步原语，如果使用进程，则应该使用进程同步原语。否则，它可能只在您的平台上工作，甚至只适用于您特定版本的Python。

Answer 3

multiprocessing和threading包的目标略有不同，尽管两者都与并发相关。threading在一个进程中协调线程，而multiprocessing提供类似线程的接口来协调多个进程.

如果您的应用程序没有生成需要数据同步的新进程，那么multiprocessing的重量就会更重一些，而threading包应该更适合。