8

作为一般规则，我阅读了一些关于SyncRoot 模式的内容，以避免死锁。阅读几年前的一个问题（请参阅此链接），我想我理解这种模式的某些用途可能是不正确的。特别是，我专注于该主题的以下句子：

您会注意到 System.Collections 中许多集合上的 SyncRoot 属性。回想起来，我认为这个属性是一个错误......请放心，我们不会犯同样的错误，因为我们构建了这些集合的通用版本。

实际上，例如，List<T>类没有实现SyncRoot属性，或者更准确地说，它是显式实现的（请参阅此答案），因此您必须转换ICollection为才能使用它。但是此评论认为，SyncRoot公开私有字段与锁定this（请参阅此答案）一样糟糕的做法，正如此评论中所证实的那样。

所以，如果我理解正确，当我实现一个非线程安全的数据结构时，因为它可以在多线程上下文中使用，我不应该（实际上，我绝不能）提供该SyncRoot属性。但我应该让开发人员（将使用此数据结构）负责将其与私有 SyncRoot 对象相关联，如以下示例代码所示。

public class A
{
    private MyNonThreadSafeDataStructure list;
    private readonly object list_SyncRoot = new object;

    public Method1()
    {
        lock(list_SyncRoot)
        {
            // access to "list" private field
        }
    }

    public Method2()
    {
        lock(list_SyncRoot)
        {
            // access to "list" private field
        }
    }
}

总之，我理解同步/锁定的最佳实践应该如下：

  1. 任何私有 SyncRoot 对象都不应通过公共属性公开；换句话说，自定义数据结构不应提供公共SyncRoot属性（另请参阅此评论）。
  2. 通常，不强制使用私有对象进行锁定（请参阅此答案）。
  3. 如果一个类有多个需要同步的操作集，但不能相互同步，则它应该有多个私有 SyncRoot 对象（请参阅此注释）。

上面写的是这个模式的正确使用吗？

4

2 回答 2

4

我会避免向SyncRoot我设计的类型添加属性，原因如下：

  • 我这种类型的用户可能需要使用不同的同步机制，例如Mutex，or ReaderWriterLockor ReaderWriterLockSlimetc

  • 类型变得更胖：它的职责变得更加分散。为什么我要添加对显式多线程锁定的支持而不支持其他绒毛？我会强迫用户只遵循一种做法，这可能不是所有情况下的最佳解决方案

  • 我需要正确实现该属性（不返回thisor typeof(MyClass)），即这是错误的：

    public object SyncRoot {get {return this;}}

我也会避免使用SyncRoot.NET 框架类型的属性。如果我需要创建一个没有SyncRoot属性线程安全的类型，我将使用一个锁定模式，如果一个类型具有此属性，我仍然不会选择锁定 on SyncRoot。这使我的代码风格一致且更易于阅读/维护。

于 2012-09-14T13:52:49.987 回答
0

这里有很多概念。首先，您正确实现的是一个线程安全的类，该类的消费者不需要自己进行同步。因此，您绝对不需要公开 syncRoot 对象。在旧的 Collection 类中，SyncRoot 属性被公开，因为这些类不是线程安全的。

锁定任意对象并锁定您的内部集合在程序的正确性或性能方面绝对没有区别。只要对两者的引用没有改变，它们就可以像 Monitor.Enter/Exit 的参数一样工作。你的内在收藏会改变吗？如果不是，也将其标记为只读。

第三，有关于基于不同操作使用不同锁的评论。典型的例子是 ReaderWriterLock。您应该根据您的类公开的不同功能分析使用不同级别的锁的需求。

于 2012-09-14T13:33:31.747 回答