c# – 为什么DateTime.Now需要线程安全？

发布时间：2020-12-15 06:18:40 所属栏目：百科来源：网络整理

导读：我正在阅读乔的Albahari C# threading tutorial：作者解释为什么DateTime.Now需要线程安全： Wrapping access to an object around a custom lock works only if all concurrent threads are aware of — and use — the lock. This may not be the case if

我正在阅读乔的Albahari C# threading tutorial：

作者解释为什么DateTime.Now需要线程安全：

Wrapping access to an object around a custom lock works only if all
concurrent threads are aware of — and use — the lock. This may not be
the case if the object is widely scoped. The worst case is with static
members in a public type. For instance,imagine if the static property
on the DateTime struct,DateTime.Now,was not thread-safe,and that
two concurrent calls could result in garbled output or an exception.
The only way to remedy this with external locking might be to lock the
type itself — lock(typeof(DateTime)) — before calling DateTime.Now.
This would work only if all programmers agreed to do this (which is
unlikely). Furthermore,locking a type creates problems of its own.

For this reason,static members on the DateTime struct have been
carefully programmed to be thread-safe.

根据MS文档,.NOW是public static DateTime Now {get; },即只读属性.
为什么麻烦线程安全,如果它是只读的？两个并发呼叫应该能够获得当前时间而不会相互干扰？

编辑：很多人,指出问题不是很清楚.
我确实做了一个假设,它应该是安全的,因为：它是只读的,因为它是时间(总是改变).

解决方法

约瑟正在举个例子.不是现在需要线程安全,所有静态方法都需要线程安全.

但是,我们来看看所有的静态场景.静态需要固有线程安全,因为如果它们有任何状态,它是有效的全局性的(因此需要线程安全),并且方法/属性的任何调用者将无法将该数据本地化,因此不需要担心线程安全.即呼叫者将无法使其线程安全可靠,因为没有其他代码可能知道该代码如何使其线程安全,因此真的不能线程安全.

例如,假设这个虚构的DateTime.Now已经被执行了(很差),如下所示：

private static long ticks;
public static DateTime Now
{
  get
  {
     ticks = UnsafeMethods.GetSystemTimeAsFileTime()
     return new DateTime(ticks); 
  }
}

…因为ticks很长,它不会在32位模式下是原子的.因此,对共享刻度的分配需要同步.约瑟说你不能这样做：

lock(somelock)
{
   var now = DateTime.Now;
}

因为任何其他代码可以自由地做到这一点：

var now = DateTime.Now;

…所以你的锁没有什么可以让它线程安全.

静态方法的消费者不可能确保对静态的调用的线程安全性,因此,静态的作者可以执行所有必要的步骤来使其线程安全.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!