仅在构造函数中使用私有setter是否使对象线程安全?

本文关键字：对象 是否 线程 安全 setter 构造函数 | 更新日期: 2023-09-27 17:51:10

我知道我可以像这样创建一个不可变的(即线程安全的)对象:

class CantChangeThis
{
    private readonly int value;
    public CantChangeThis(int value)
    {
        this.value = value;
    }
    public int Value { get { return this.value; } } 
}

然而，我通常会"作弊"，并这样做:

class CantChangeThis
{
    public CantChangeThis(int value)
    {
        this.Value = value;
    }
    public int Value { get; private set; } 
}

然后我想知道，"为什么这个工作?"它真的是线程安全的吗?如果我像这样使用:

var instance = new CantChangeThis(5);
ThreadPool.QueueUserWorkItem(() => doStuff(instance));

那么它真正在做的是(我认为):

  1. 为实例分配线程共享堆空间
  2. 初始化堆上实例内部的值
  3. 将指向该空间的指针/引用写入本地变量(线程特定的堆栈)
  4. 将引用作为值传递给该线程。(有趣的是，我写它的方式，引用是在闭包内，这是做同样的事情，我的实例正在做，但让我们忽略它。)
  5. 线程进入堆并从实例中读取数据。

但是，实例值存储在共享内存中。这两个线程可能具有堆上该内存的缓存不一致视图。是什么确保线程池线程实际上看到了构造的实例，而不是一些垃圾数据?在任何对象构造的末尾是否存在隐式内存屏障?

仅在构造函数中使用私有setter是否使对象线程安全?

  • 将指向该空间的指针/引用写入本地变量(线程特定的堆栈)
  • 初始化堆上实例内部的值

不…转化。它更类似于:

  • 为对象分配内存
  • 构造函数被称为
  • 对内存/对象的引用从new操作符/关键字
    • "返回"
  • 引用被"保存"在var instance (=赋值操作符)

可以通过在构造函数中抛出异常来检查。引用变量不会被赋值。

一般来说，你不希望另一个线程能够看到半初始化的对象(注意，在Java的第一个版本中，这并不能保证…Java 1.0有所谓的"弱"内存模型)。这是怎么得到的呢?

在Intel上是保证的:

x86-x64处理器不会对两个写操作重新排序，也不会对两个读操作重新排序。

这是非常重要的:-)，它保证了问题不会发生。这个保证不是。net或ECMA c# 的一部分，但是在Intel上，是由处理器保证的，而在Itanium(一个没有这个保证的架构)上，这是由JIT编译器完成的(见相同的链接)。似乎在ARM上这是不保证的(仍然是相同的链接)。但我没见过有人提起过。

一般来说，在上面的例子中，这并不重要，因为:

几乎所有与线程相关的操作都使用完整的内存屏障(参见内存屏障生成器)。一个完整的Memory Barrier保证在Barrier之前的所有写和读操作都在Barrier之前真正执行，并且在Barrier之后的所有读/写操作都在Barrier之后执行。ThreadPool.QueueUserWorkItem肯定在某一点上使用一个完整的内存屏障。并且启动线程必须明确地以"新"开始，因此它不能有陈旧的数据(并且通过https://stackoverflow.com/a/10673256/613130， 我认为可以安全地假设您可以依赖隐式屏障。)

请注意，英特尔处理器自然是缓存一致的…如果你不想要它，你必须手动禁用缓存一致性(参见例如这个问题:https://software.intel.com/en-us/forums/topic/278286)，所以唯一可能的问题将是在寄存器中"缓存"的变量或预期的读取或写入延迟(这两个"问题"都是通过使用全内存屏障来"修复"的)

附录

这两段代码是等价的。自动属性只是一个"隐藏"字段加上一个样板get/set，分别是return hiddenfield;和hiddenfield = value。因此，如果代码的v2有问题，那么代码的v1也会有同样的问题:-)

如果没有绕过语言级块来调用setter(这可以通过反射完成)，那么您的对象将保持不可变和线程安全，就像使用只读字段一样。

关于共享内存和缓存不一致视图，这些是由框架、操作系统和硬件处理的细节，所以在编程像这样的高级程序时不需要担心它们。

相关文章：