爲什麼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的實現相當簡單，可能並沒有考慮到其中的許多問題。他們的「不安全」評論是「這裏有龍」 - 如果您嘗試在併發應用程序中使用它，您可能會/很難排除併發錯誤或問題。