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

概述我正在阅读乔的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 我正在阅读乔的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;

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

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

总结

以上是内存溢出为你收集整理的c# – 为什么DateTime.Now需要线程安全？全部内容，希望文章能够帮你解决c# – 为什么DateTime.Now需要线程安全？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。