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

Question

在Twisted API for DeferredFilesystemLock中，指出deferUntilLocked对于并发使用不安全。

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

Answer 1

可以说这个方法对于并发使用来说实际上非常安全。如果您阅读the first four lines of the implementation，则很明显尝试并发使用会立即提升AlreadyTryingToLockError。

也许这个警告是为了告诉你，你会得到一个例外，而不是有用的锁定行为。

该异常的实现应该提供关于为什么不允许并发使用的提示。 DeferredFilesystemLock使用一些实例属性（从_tryLockCall开始）来跟踪尝试获取锁定的进度。如果允许并发尝试，他们将互相践踏这个属性（和其他人）的使用。

这可以相对容易地增强。所有必要的是保持与锁定尝试相关联的状态在每次尝试分配的新对象上（而不是在DeferredFilesystemLock实例上）。 Or, DeferredLock could help.

Answer 2

第一个也是最明显的事情是，在并发情况下，你永远不能保证获得锁（如果另一个线程永远不会释放它），所以你可能永远defer。您可以通过简单地将可选timeout传递给deferUntilLocked来避免这种情况。

要考虑的其他因素可能会使其不适合并发使用：

• 饥饿：如果多个线程不断等待获取相同的锁 - 如果它们被公平对待，或者一个线程花费的时间比其他线程长？是否保证线程最终获得锁定？

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

• 你确定获得的锁总是被释放吗？如果一个线程获得一个锁并在没有释放的情况下崩溃该怎么办？

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