multithreading - 是否有任何理由在递归锁上使用常规锁？

Question

当一个线程尝试再次获取它已经持有的递归锁时，rlock.acquire()允许该线程继续并且不阻塞该线程。

另一方面，当一个线程试图获取它已经持有的常规锁时，该线程就会陷入死锁。

在我看来，第二种情况只是一个麻烦的来源，因为它是一种无法轻易恢复的情况（线程只是卡lock.acquire()在只是卡住了）。

到目前为止，我已经看过很多次了，有人实际上想使用 anRLock但使用的是常规Lock并花了一段时间调试该问题。而另一方面，我从未遇到过 aLock实际上会更好的情况。可以说，当代码的关键部分不应被同一线程一次访问两次时，可以使用它，但要发生这种情况，该关键部分内的代码需要调用自身，这将是一些事情这对程序员来说应该很明显。

那么，有没有Lock比 an 更好的情况RLock？如果没有，语言设计者是否应该继续提供常规Lock？

标签： multithreadinglocking

Answer 1

假设这些是 Python 锁定对象，文档显示它们完全不同。两者的主要区别在于：

• 锁可以被任何线程释放，而不仅仅是获得它的线程
• 一个 Rlock 只能被获取的线程释放
• 线程每次获取 Rlock 都必须释放一次

因此，锁允许您构建线程方案，其中锁在一个线程中获取但在另一个线程中释放。一个例子可能是处理一件工作的线程管道，工作分配器获得锁，但它被管道中的最后一个线程释放。