代码之家  ›  专栏  ›  技术社区  ›  Paul Stovell

是否应请求锁定超时。网?

  •  6
  • Paul Stovell  · 技术社区  · 17 年前

    在……里面 Release It! 他们的 僵局的可能性。突然之间,服务器根本没有响应,因为线程池已耗尽,这导致负载均衡器将流量转移到其他服务器(它们都运行相同的代码),从而增加了流量 他们的

    但是,您可以致电 Monitor.TryEnter(lockObject, TimeSpan) 请求锁定或超时。如果超时到期且无法获取锁,则返回false。有些人有 wrapped this in using statements

    4 回复  |  直到 17 年前
        1
  •  6
  •   TheSmurf    17 年前

    我通常会使用超时。这里最大的问题是,如果达到超时,请求操作将被中止。这显然比陷入僵局要好。不过还有一个更大的问题:如果操作很关键,而你因为其他事情陷入僵局而开始中止,如果你的设计不合理,你最终可能会导致你通过这种方法描述的农场停机问题(虽然更软:你的应用程序将不再工作,但你并没有失去控制)。

    主要区别在于,你实际上在这里有控制权,而如果线程开始死锁,一旦失败开始,你就无法在代码中解决问题。

        2
  •  1
  •   ctacke    17 年前

    一般来说,I 从不 创建具有无限超时的锁。它只会导致死锁难以发现和调试。添加超时检查不需要任何额外的工作,即使它只是抛出一个异常,如果你有死锁,它几乎会立即通知你。更重要的是,它可以帮助您找到由可能不会导致完全死锁的锁引起的瓶颈。

        3
  •  1
  •   Stu Mackellar    17 年前

    你能从锁定尝试超时的情况中优雅地恢复过来吗?如果可以的话,请务必使用超时。如果你不能,那么超时就没有多大意义。当你恢复执行时,你打算做什么?您最多只能退出并显示错误消息。超时有其用途,但也可以用来隐藏微妙的线程错误,所以我认为最好的建议是谨慎使用。

        4
  •  0
  •   Eduard - Gabriel Munteanu    17 年前

    可以证明死锁不会发生。也可以在运行时证明即使不依赖于竞争条件也会发生死锁(参见Linux的 lockdep 例如)。

    因此, 总是 尝试锁是没有意义的。这取决于具体情况。