2

在DeferredFilesystemLock 的 Twisted API 中，声明deferUntilLocked并发使用是不安全的。

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

4

2 回答 2

2

可以说，该方法实际上对于并发使用是相当安全的。如果您阅读了实现的前四行，那么很明显，并发使用的尝试将立即引发AlreadyTryingToLockError.

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

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

这可以相对容易地得到加强。所需要做的就是保持与每次尝试分配的新对象（而不是DeferredFilesystemLock实例）上的锁定尝试相关联的状态。 或者，DeferredLock可以提供帮助。

于 2013-09-26T11:30:00.743 回答
1

首先想到的也是最明显的事情是，在并发情况下，您永远无法保证获得锁（如果另一个线程永远不会释放它），所以您可能defer永远。您可以通过简单地将可选参数传递timeout给deferUntilLocked.

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

  • 饥饿：如果多个线程不断地等待获取同一个锁怎么办——它们是否得到公平对待，或者一个线程会比其他线程花费更长的等待时间？线程是否保证最终获得锁？

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

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

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

于 2013-09-26T04:24:14.640 回答