c# - 关于 SyncRoot 模式 : what is the correct way to use this pattern? 的一些说明

Question

我阅读了一些有关SyncRoot 模式 的内容，将其作为避免死锁的一般规则。阅读几年前的一个问题(参见 link)，我想我明白这种模式的某些用法可能不正确。特别是，我专注于 this topic 中的以下句子:

You’ll notice a SyncRoot property on many of the Collections in System.Collections. In retrospeced, I think this property was a mistake... Rest assured we will not make the same mistake as we build the generic versions of these collections.

其实比如List<T>类没有实现 SyncRoot属性，或者更准确地说，它是显式实现的(请参阅 this answer )，因此您必须转换为 ICollection为了使用它。但是this comment争辩说私有(private) SyncRoot现场公众与锁定 this 一样糟糕(参见 this answer )，同样在 this comment 中得到证实.

所以，如果我理解正确的话，当我实现一个非线程安全的数据结构时，因为它可以在多线程上下文中使用，所以我不应该(实际上，我不能)提供 SyncRoot属性(property)。但我应该让开发人员(他们将使用此数据结构)完成将其与私有(private) 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. 任何私有(private) SyncRoot 对象都不应通过公共(public)属性公开；换句话说，自定义数据结构不应提供公共(public) SyncRoot。属性(property)(另见 this comment )。
2. 一般来说，不强制使用私有(private)对象进行锁定(参见 this answer )。
3. 如果一个类有多组操作需要同步，但彼此之间不需要同步，则它应该有多个私有(private) SyncRoot 对象(参见 this comment)。

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

Answer 1

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

• 我这种类型的用户可能需要使用不同的同步机制，例如Mutex , 或 ReaderWriterLock或 ReaderWriterLockSlim等等

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

• 我需要正确实现该属性(不返回 this 或 typeof(MyClass))，即这是错误的:

  public object SyncRoot {get {return this;}}
  

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