尽管从文档中还不能完全清楚这一点，但是多处理同步原语实际上也确实可以同步线程。
例如，如果您运行以下代码：
import multiprocessingimport sysimport threadingimport timelock = multiprocessing.Lock()def f(i): with lock: for _ in range(10): sys.stderr.write(i) time.sleep(1)t1 = threading.Thread(target=f, args=['1'])t2 = threading.Thread(target=f, args=['2'])t1.start()t2.start()t1.join()t2.join()
…输出将始终为
1111111111222222222或
22222222221111111111，而不是两者的混合。
这些锁是在Windows的Win32内核同步对象之上，在支持它们的POSIX平台上的信号量之上实现的，而在其他平台上根本没有实现。（您可以使用进行测试
importmultiprocessing.semaphore，这将
importError在其他平台上引发，如文档中所述。）
话虽这么说，只要您始终按正确的顺序使用两个级别的锁，那肯定是 安全的
—也就是说，
threading.Lock除非可以保证您的进程具有，否则不要抓住它们
multiprocessing.Lock。
如果足够巧妙地执行此操作，则可以提高性能。（在Windows和某些POSIX平台上，跨进程锁可能比进程内锁慢几个数量级。）
如果您仅以明显的方式执行此操作（仅在
with threadlock:内部
withprocesslock:块中执行），则显然对性能无济于事，并且实际上会使速度变慢（尽管可能不足以衡量），并且不会添加任何内容直接收益。当然，即使读者不知道
multiprocessing线程之间的锁是有效的，您的读者也会知道您的代码是正确的，并且在某些情况下，调试进程内死锁比调试进程间死锁要容易得多……但是我认为这两者都不是。在大多数情况下，这是一个足够复杂的理由。
