【问题标题】:What is the benefit of this .Net pattern这种 .Net 模式有什么好处
【发布时间】:2023-04-05 20:14:01
【问题描述】:

我一直在寻找一种能够同时提供同一类的线程安全和不安全版本的模式。这其中的技术方面非常明显。我想是希望找到命名/访问约定等...

所以我在“Systems.Collections”命名空间中到处都能找到这种模式:

public class WhatEv
{
    private class SyncWhatEv : WhatEv
    {
        // overrides IsSyncronized = true
        // overrides whatever else to make it thread safe
    }

    public virtual bool IsSynchronized
    {
        get { return false; }  
    } 

    public static WhatEv Synchronized(WhatEv whatEv)
    {
        return new SyncWhatEv(whatEv);
    }
}

有许多类可以实现这个:HashTable、Queue、ArrayList、Stack 等……我理解继承。但是为什么要让它成为一个私有的、嵌套的类并让用户跳过一个圈子来获得它呢?这样做有什么好处吗?

【问题讨论】:

  • 感谢您迄今为止的意见。我只是想想象一个场景,其中用户想要接收基类而不知道它是线程安全的。如果接收者是线程,它应该需要线程安全版本,对吗?如果接收者不是,那它为什么要关心?
  • 如果您将从两个线程访问它,则两者都需要使用相同的同步实例。您不能只让接收者使用同步实例,而主线程使用非同步版本。因此,如果该对象有任何机会被另一个线程访问,则应该对其进行同步。但请参阅 Joel 对一个潜在问题的回答。
  • @Naked - 同意。但是 SyncWhatEv 继承了 WhatEv。因此,SyncWhatEv 的同一个实例可以在主线程上作为 WhatEv 类型使用,并且工作线程需要作为 SyncWhatEv 类型。只是,这是不可能的,因为 SyncWhatEv 是私有的。目前,线程必须仔细检查 IsSynchronized 并在为 false 时抛出。

标签: .net synchronization thread-safety design-patterns


【解决方案1】:

在周末思考这个问题之后,没有得到进一步的回应。我决定答案是:你们都疯了。提供对象的同步版本的全部目的是为了线程安全,但是线程在编译时无法要求对象的线程安全版本。这个对象的验证必须在运行时进行,这是......伪造的。

感谢大家的意见。我很感激。

【讨论】:

  • 可爱。无缘无故的-1。如果我不正确,请告诉我我错了。
【解决方案2】:

理论上,这是个好主意,@CodeNaked 有很好的解释。在实践中,这仍然存在问题。例如,如果您需要对线程安全类进行 2 次调用,并且需要为两个调用组合使用线程安全,那么您仍然需要进行锁定。在这个 SO 项目中有很好的解释:In C# would it be better to use Queue.Synchronized or lock() for thread safety?

【讨论】:

  • 优秀的链接。我同意自己进行锁定是一种更精致的方法。我仍然认为,作为一种模式,它对我来说没有意义。
【解决方案3】:

在大多数情况下,不需要对象的线程安全版本(即 Hashtable、Queue)。因此,添加默认情况下使其成为线程安全所需的开销是没有意义的。使用 Synchronized 方法,让需要线程安全的用户获得线程安全的版本。

对象的同步版本不添加任何额外的功能,除了线程安全。他们不会暴露任何新成员,也不会知道他们的底层类型真的有帮助。因此它们被设为私有,并且简单地“看起来”像它们的公共/基类。

【讨论】:

  • 如果您要花钱创建线程安全版本,为什么不放弃非线程安全版本而只维护一个版本?
  • @BenCr - 因为存在性能损失以确保线程安全。正如我所说,通常大多数情况下不需要线程安全,但是当你这样做时它就在那里。此外,大多数编码方式,您通常可以在 Hashtable 中修复某些内容,它也可以在私有线程安全版本中修复。因为后者只关心确保获得正确的锁。
  • @BenCr,我听到你在说什么。我对锁的性能成本并不过分偏执,但我的类可以广泛用于单线程上下文中,偶尔也可以在线程上下文中使用(我敢肯定,就像大多数这些类一样)。在 90% 的情况下不需要所有锁定似乎有点矫枉过正。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-03-15
  • 2010-09-14
  • 1970-01-01
  • 1970-01-01
  • 2018-01-11
相关资源
最近更新 更多