C# 4.0：是否有现成的、线程安全的自动实现属性？

Question

我希望对自动实现的属性进行线程安全的读写访问。我缺少 C#/.NET 框架中的此功能，即使在最新版本中也是如此。 充其量，我希望得到类似的结果

[Threadsafe]
public int? MyProperty { get; set; }

：我知道有各种代码示例可以实现此目的，但我只是想在自己实现某些内容之前确保仅使用 .NET 框架方法仍然无法实现此目的。我错了吗？

编辑：由于一些答案详细阐述了原子性，我想说，据我所知，我只是想拥有它：只要（且不超过）一个线程正在读取属性的值，不允许其他线程更改该值。因此，多线程不会引入无效值。我选择了int？类型，因为这是我目前关心的。

编辑2：我在这里找到了 Nullable 示例的具体答案，作者：Eric利珀特

Answer 1

正确的;没有这样的设备。想必您正试图防止在另一个线程更改了该字段的一半（原子性）时读取该字段？请注意，许多（小）原语本质上是安全的，不会出现这种类型的线程问题：

5.5 变量引用的原子性

读取和写入以下数据
类型是原子的：bool、char、byte、
sbyte、short、ushort、uint、int、
浮点和引用类型。在
枚举的加法、读写
具有基础类型的类型
之前的列表也是原子的。

但老实说，这只是线程冰山一角； 本身通常仅仅拥有线程安全属性是不够的；大多数情况下，同步块的范围必须大于一次读/写。

还有很多不同的方法可以使某些东西成为线程安全的，具体取决于访问配置文件；

• 锁定？
• ReaderWriterLockSlim ？
• 引用交换到某个类（本质上是一个 Box，因此在本例中是一个 Box）
• Interlocked（在所有的伪装）
• 易失性（在某些情况下；它不是魔杖......）
• 等

（更不用说使其不可变（通过代码，或者只是选择不改变它，这通常是使其成为线程安全的最简单方法）

Answer 2

我在这里回答是为了补充 Marc 的答案，他说“还有很多不同的方法可以使某些东西成为线程安全的，具体取决于访问配置文件”。

我只是想补充一点，部分原因是有很多方式不线程安全，当我们说某件事是线程安全的时，我们必须明确取决于所提供的安全性。

对于几乎所有可变对象，都会有一些非线程安全的方法来处理它（注意几乎任何，都会出现异常）。考虑一个具有以下（线程安全）成员的线程安全队列；入队操作、出队操作和计数属性。通过在每个成员上进行内部锁定，或者甚至使用无锁技术，构建其中一个相对容易。

但是，假设我们像这样使用该对象：

if(queue.Count != 0)
    return queue.Dequeue();

上面的代码不是线程安全的，因为不能保证（线程安全的）Count 返回 1 之后，另一个线程不会出队并且从而导致第二次操作失败。

在很多方面它仍然是一个线程安全的对象，特别是即使在这种失败的情况下，失败的出队操作也不会将对象置于无效状态。

为了使对象在面对任何给定的操作组合时作为一个整体线程安全，我们必须使其在逻辑上不可变（可以通过线程安全操作更新内部状态作为优化来实现内部可变性 - 例如通过记忆或根据需要从数据源加载，但对于外部它必须显得不可变）或者严重减少可能的外部操作的数量（我们可以创建一个只有 Enqueue 和 的线程安全队列TryDequeue 始终是线程安全的，但既减少了可能的操作，也强制将失败的出队重新定义为不是失败，并强制更改我们之前版本的调用代码的逻辑） 。

其他任何事情都是部分保证。我们免费获得了一些部分保证（正如 Marc 指出的那样，就单个原子而言，作用于某些自动属性已经是线程安全的了——在某些情况下，这就是我们所需要的所有线程安全性，但在其他情况下却无济于事）近得足够远）。

让我们考虑一个属性，该属性将这种部分保证添加到我们尚未获得的情况下。它对我们到底有多大价值？嗯，在某些情况下它会是完美的，但在其他情况下却不会。回到出队前的测试案例，对 Count 进行这样的保证并没有多大用处 - 我们有这样的保证，但代码在多线程条件下仍然会失败，而它不会以某种方式失败在单线程条件下。

更重要的是，将这种保证添加到尚不具备这种保证的情况下至少需要一定程度的开销。一直担心开销可能是不成熟的优化，但增加开销却没有收益是过早的悲观情绪，所以我们不要这样做！更重要的是，如果我们确实提供更广泛的并发控制来使一组操作真正线程安全，那么我们将使更窄的并发控制变得无关紧要，并且它们变成纯粹的开销 - 所以我们甚至无法从我们的操作中获得价值某些情况下的开销；这几乎总是纯粹的浪费。

还不清楚并发问题的范围有多大。我们是否需要仅锁定（或类似）该属性，还是需要锁定所有属性？我们是否还需要锁定非自动操作，这可能吗？

这里没有好的单一答案（在滚动您自己的解决方案时，它们可能是棘手的问题，更不用说尝试在其他人使用此 [Threadsafe] 属性时生成此类代码的代码中回答它）。

此外，任何给定的方法都会有一组不同的条件，在这些条件下可能会发生死锁、活锁和类似问题，因此我们实际上可以通过将线程安全视为我们可以盲目应用于属性的东西来降低线程安全性。

如果无法找到这些问题的单一通用答案，就没有提供单一通用实现的好方法，并且任何此类 [Threadsafe] 属性充其量也将具有非常有限的价值。最后，在使用它的程序员的心理层面上，很可能会导致一种错误的安全感，即他们创建了一个线程安全的类，而实际上他们没有创建这个类；这实际上会比无用更糟糕。

Answer 3

不，不可能。这里没有免费的午餐。当您的自动属性需要更多提示（线程安全，INotifyPropertyChanged）时，您就需要手动完成 - 没有自动属性魔法。

Answer 4

根据 C# 4.0 规范，此行为保持不变：

第 10.7.3 节 自动实现的属性

当属性被指定为自动实现的属性时，隐藏的支持字段将自动可供该属性使用，并且访问器被实现来读取和写入该支持字段。

以下示例：

 public class Point {
    public int X { get; set; } // automatically implemented
    public int Y { get; set; } // automatically implemented
}

相当于以下声明：

public class Point {
    private int x;
    private int y;
    public int X { get { return x; } set { x = value; } }
    public int Y { get { return y; } set { y = value; } }
}