是否有任何理由使用 threading.Lock 而不是 multiprocessing.Lock？答案

【问题标题】：Is there any reason to use threading.Lock over multiprocessing.Lock?是否有任何理由使用 threading.Lock 而不是 multiprocessing.Lock？
【发布时间】：2010-12-31 03:07:31
【问题描述】：

如果软件项目支持多处理已向后移植到的 Python 版本，是否有任何理由使用 threading.Lock 而不是 multiprocessing.Lock？ multiprocessing 锁也不是线程安全的吗？

就此而言，是否有理由使用来自threading 的任何同步原语也在multiprocessing 中？

【问题讨论】：

标签： python multithreading process locking multiprocessing

【解决方案1】：

我希望多线程同步原语更快，因为它们可以轻松使用共享内存区域。但我想你必须进行速度测试才能确定。此外，您可能会产生非常不希望的副作用（并且在文档中未指定）。

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

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

【讨论】：

在我的程序中，有多个线程和进程。我也可以使用 multiprocessing.Lock 进行线程同步吗？

【解决方案2】：

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

如果您的应用程序不会产生需要数据同步的新进程，multiprocessing 的重量会更大一些，threading 包应该更适合。

【讨论】：

我了解线程和多处理之间的区别。我很好奇为什么要使用线程的同步原语而不是多处理。

【解决方案3】：

线程模块的同步原语比多处理更轻，更快，因为缺少处理共享信号量等。如果你使用线程；使用线程的锁。进程应该使用多进程的锁。

【讨论】：

更不用说multiprocessing 的便携性不如threading ;)
在我的程序中，有多个线程和进程。我也可以使用 multiprocessing.Lock 进行线程同步吗？
就像确认一样，获取和释放 100,000 个线程锁需要 0.07 秒，而使用 100,000 个多处理锁需要 8.1 秒。