.NET线程安全

H2O*_*aCl 8 .net thread-safety

List.Add是一个实例成员.这意味着它不能保证是线程安全的.这是什么意思?

可能性1.如果两个线程在不同的实例上调用.Add,根据月亮的相位可能会出现意外的结果?

可能性2.如果两个线程在同一个实例上调用.Add,则根据月亮的相位可能会出现意外结果,如果实例不同则没有潜在问题.

可能性3.微软根本不希望人们使用线程,所以他们写.NET是模棱两可的.

Jon*_*nna 10

可能性1并非如此.对于一个实例方法来说,为其他实例引起问题是非常不寻常的,这可以清楚地记录下来(不仅仅是声明指出这一点,而且还有一些理由,因为这通常是编码非常糟糕的迹象,所以如果有一个很好的理由,它会被指出).

可能性3并非如此,因为他们刚刚记录了线程行为.

可能性2部分就是这种情况.但是,交互也可以是一个调用Add的线程,另一个调用另一个非线程安全的实例方法.

框架提供的大多数可变类是静态成员的线程安全和实例方法的非线程安全.这是有充分理由的.

  1. 如果静态方法不是线程安全的,则很难以线程安全的方式调用该方法,特别是如果该类可能由不同人编写的不同代码层使用.这使得使这些方法线程安全的努力几乎总是合理的.大多数这样的成员也相对容易制作线程安全(如果避免具有可变的静态状态,这总是一件好事可以避免).

  2. 单个对象的大量使用将一次由一个线程进行,而不会被另一个线程访问.这使得难以确保正确性,如果出现问题则存在死锁风险,以及强加于性能的开销,难以证明其合理性.对于使用该类的人来说,确保多线程使用的实例以线程安全的方式使用也相对容易.

由于编写线程安全代码并不总是那么容易,因此在那里"非常重视""相对".有时它很容易(不可变的类需要一些工作才能使非线程安全!),但更常见的是它非常难(因此在这里和其他地方有很多关于这个主题的问题).

然而,这正是在这种情况下应该给用户带来负担的原因.为了使这样一个类完全线程安全是如此困难(实际上,有时可证明是不可能的),结果对于大多数用户来说是不可接受的,他们是最能判断在给定情况下需要什么保护的人.

  • +1:干得好,我喜欢详细的分析. (2认同)