代码之家  ›  专栏  ›  技术社区  ›  zoidbeck

公开可见的锁对象:有时对设计缺陷有用或有指示作用?

  •  2
  • zoidbeck  · 技术社区  · 15 年前

    我正在监控一个管理一些低级网络通信的软件组件的分包供应。查看此组件时,我发现:

    public static object SyncRoot { get { return syncRoot; } }
    

    在这个非常重要的类中,几乎任何方法都在执行操作时使用这个锁对象。现在我想知道这是不是一个好的决定来实现这样一个瓶颈,还是它毕竟是一个严重的设计缺陷。这难道不是一种奇怪的多线程过程方式吗?

    另外,可能的死锁问题是锁得快吗?管理所有这些concurrend线程的监视效率有多高? 如果有必要的话,实现一个同步的暂停/恢复方法来让这个类从外部停止/开始工作不是更好吗? 在什么情况下使用公开可见的锁对象?有吗?

    3 回复  |  直到 15 年前
        1
  •  2
  •   phoog    15 年前

    Public SyncRoot在MS框架中使用,这是真的,但那是一个实例属性,而不是一个静态属性。在您的示例中,您没有提供有关(静态)syncRoot属性返回的syncRoot对象的范围或可访问性的任何详细信息。文档(http://msdn.microsoft.com/en-us/library/ms173179.aspx)警告不要锁定公共类型或“超出应用程序控制”的对象。在 http://www.albahari.com/threading/ .

        2
  •  1
  •   Steven    15 年前

    这个 SyncLock 本质上是.NET框架中的一个设计缺陷。因此,.NET2.0集合不会直接公开此属性(它是显式实现的,并且是向后兼容所必需的)。问题是锁定通常是细粒度的,锁定发生的级别太低。通常,可以通过在控制集合的更高级别组件上锁定来解决此问题。

    使用 SyncRoot 属性确实存在死锁的更改,因为您无法控制使用者如何使用该锁定对象。他们可能还要锁很长时间,或者忘记开锁。暂停/恢复的想法听起来很可怕。

    通常的做法是使组件线程安全。当你这样做的时候,你就不需要 同步根 财产。

        3
  •  0
  •   Dean Chalk    15 年前