在那些简单的情况下使用 C# 锁有用吗？ [复制]

Question

在多线程环境中，锁定线程敏感资源很重要。我经常假设集合等是线程不安全的，这取决于 MS 文档，但简单类型也是线程敏感的吗？

让我们举个例子。锁定int属性访问是否有用，例如

public int SomeProperty
{
    get
    {
        lock (_lock)
        {
             return _value;
        }
    }
}

或者是一个普通的吸气剂就足够了，即

public int SomeProperty => _value;

据我了解，简单的字段读取是线程安全的，但我仍然在网络和某些代码存储库中看到第一个示例。

第二个问题，单行指令中的值是顺序读取还是同时读取？换句话说，我这样做时是否需要锁定

public TimeSpan GetSomeExampleValue()
{
    lock (_lock)
    {
        return _dateTime1 - _dateTime2;
    }
}

或者我可以简单地做吗

public TimeSpan GetSomeExampleValue()
{
    return _dateTime1 - _dateTime2;
}

Answer 1

注意：这里的一切都是基于有效锁定； lock 与 int（在第一个示例中为 lock (_value)）是非常糟糕的事情，并且提供零保护；不要那样做！编译器可能已经对你大喊大叫了（你应该只锁定引用类型，否则它每次都会装箱并给你一个不同的对象，因此每次都有不同的锁定）。

据我了解，简单的字段读取是线程安全的，

比这要复杂得多。首先，您需要定义线程安全！您可能指的是三种不同的场景：

1. 避免“撕裂”值 - 在写入发生时读取的不一致的单个值并且具有（通常）一半来自之前/之后值的一半，另一半来自另一个 - 创建第三个虚幻值逻辑上从未存在过；在这里，我们需要考虑“原子性”——C# 语言定义的类型始终是原子安全的，其中包括 int 和引用，但 不 包括 DateTime；因此，int 示例在这里是安全的，但 DateTime 值不是（但是，在实践中，在 64 位进程中，您应该可以使用高达 64 位的结构，但是：这不能保证由 C# 规范 - 在 CLR 规范中提到）
2. 避免多个值之间的不一致状态；再次考虑DateTime 值——即使我们不撕任何东西，我们也可以从更新的一侧获得_dateTime1，从另一侧获得_dateTime2，这意味着我们返回的TimeSpan 是一个幻像值不代表两个字段的任何一致的逻辑状态
3. 内部 CPU 优化，例如乱序读/写，这意味着我们得到了非常奇怪的结果

现在

• 没有lock，int仍然免疫撕裂，但易受其他撕裂； DateTime 易受这三个因素的影响
• 与lock，两者都完全防范所有三个

您可能还希望将不变性视为简化逻辑的一种方式，但请记住，readonly 是一个谎言 - 指南而不是实际规则。