为什么Twisted的DeferredFilesystemLocks对并发使用不安全？

Question

在Twisted API for DeferredFilesystemLock中，声明{}并发使用不安全。在

我想了解它在什么方面不安全，什么使它不安全，以确保我不会滥用文件锁。在

Answer 1

可以说，这种方法对于并发使用实际上是相当安全的。如果您阅读the first four lines of the implementation，那么很明显，并发使用的尝试将立即引发AlreadyTryingToLockError。在

也许这个警告是为了告诉您，您将得到一个异常，而不是有用的锁定行为。在

该异常的实现应该提供一个提示，说明为什么不允许并发使用。DeferredFilesystemLock使用一些实例属性，从_tryLockCall开始，跟踪获取锁的过程。如果允许并发尝试，它们将彼此践踏该属性（以及其他属性）的使用。在

这可以相对容易地得到加强。所有需要做的就是保持与每次尝试分配的新对象的锁尝试相关联的状态（而不是在DeferredFilesystemLock实例上）。Or, ^{} could help.

Answer 2

首先想到的也是最明显的一点是，在并发情况下，您永远无法保证获得锁（如果另一个线程从不释放它），所以您可能永远defer。只需将可选的timeout传递给deferUntilLocked，就可以避免这种情况。在

其他需要考虑的事项可能使其不适合同时使用：

• 饥饿：如果多个线程一直在等待获取同一个锁呢？它们是否得到公平对待，或者一个线程的等待时间会比其他线程长？线程是否保证最终获得锁？

• 死锁：如果一次获取多个锁，而多个线程正在执行此操作，则可能会遇到这样的情况：两个线程都在等待另一个线程持有的资源。

• 您确定获取的锁总是被释放吗？如果一个线程获得了一个锁却没有释放它就崩溃了呢？

在我看来，Twisted的实现相当简单，可能没有考虑到其中的许多内容。他们的“不安全”评论是“这里有龙”—如果您试图在并发应用程序中使用它，您可能/将很难解决并发错误或问题。在