Why DateTime.Now needs to be thread-safe?

Question

I am Reading Joe's Albahari C# threading tutorial:

Author explains why DateTime.Now needs to be thread-safe:

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.

According to MS docs, .NOW is public static DateTime Now { get; }, i.e. read-only property. Why bother with thread-safety, if it is read-only ? Two concurrent calls should be able to get the current time without interfering with each other ?

Edit: A lot of people, pointing out that questions is not very clear. I did make an assumption that it should be safe, because: it is read only and because it is time(always changing).

Answer 1

Joseph is giving an example. It's not that Now needs to be thread-safe, all static methods need to be thread safe.

But, let's look at the all statics scenario. Statics need to be inherently thread-safe because if they have any state it is effectively global (and thus have a need to be thread-safe) and any caller to the method/property would be unable to make that data local and thus not need to worry about thread-safety. i.e. the caller would not be able to make it thread-safe reliably because no other code could possibly know how this code tried to make it thread safe and thus really can't be thread safe.

For example, let's say this fictitious DateTime.Now was implemented (poorly) like this:

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

...because ticks is long, it will not be atomic in 32-bit mode. Thus, the assignment to the shared ticks needs to be synchronized. Joseph is saying that you can't simply do this:

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

...because any other code is free to do this:

var now = DateTime.Now;

...and thus your lock does nothing to make it thread-safe.

It's impossible for a consumer of a static method to ensure thread-safety of the call to the static, thus the onus is on the writer of the static to perform all the necessary steps to make it thread-safe.

Answer 2

Here's a Get that is not thread safe:

private string whyWouldYouDoThis;
public string NotThreadSafe
{
    get
    {
        whyWouldYouDoThis = "Foo";
        whyWouldYouDoThis += "Bar";
        return whyWouldYouDoThis;
    }
}

Thankfully the optimizer would probably see this and think "what..." and fix this for you, but as is, one thread could build "FooBar", be interrupted, the 2nd thread resets to "Foo" and now the first thread returns "Foo". Boom, race condition.

This is why even gets may require additional work to be thread-safe. Note the use of a private field? I'm willing to bet that this scenario was so common that it inspired the .Net's team policy of declaring all non-static methods and properties as non-thread safe by default. Special care was taken to make all static's thread-safe.

This is also an important reminder that multi-threading is hard, because most .Net languages don't make it obvious what is thread safe. Most of us think procedurally when we code, so it's not immediately apparent when we code a race condition. Use parallelism only if you have evidence you need it.

As Kamel BRAHIM points out, static and Get ("Read-only") does not guarantee thread safety. Immutability (the 'readonly' keyword) does, and this is true regardless of the type being returned, whether it's a string or a DateTime.

Answer 3

Being thread safe does not always require any synchronisation.

Eg.

public static int One {
  get {
    return 1;
  }
}

is thread safe without any special coding.

Remember the .NET coding guidelines: static members should be thread safe (ie. unless documented otherwise), so this is the default position. But this guideline says nothing about any steps necessary to achieve that: it can be zero effort.

A read only property that cached the current value (maybe it is expensive to determine, but doesn't change much) may need to synchronise the cache, perhaps using a Monitor, but how thread safety is achieved is an implementation detail.

Edit To address the comment "doesn't address the question": because otherwise – DateTime.Now is not thread safe – every program would need to provide its own synchronisation around every call to DateTime.Now. (I considered the underlying question to be "the guideline says I should do X, but X is implicit, what should I do?" to which the answer is: "if you get compliance for free, then accept it".)

Answer 4

Each call to DateTime.Now needs to actually get the current time from some common mutable resource (the current time is changing after all; it's not like its constant). Accessing a common mutable resource from multiple threads means you need to be sure that you do so in a safe manner.

Answer 5

Imagine if Now is implemented like:

public static DateTime Now { get { return internalToday + internalCurrentTime; } }

and we are not declaring it thread safe - meaning "this method will work correctly only when used in single threaded environment".

So if you use such method from multiple threads it is possible to get results like "Yesterday 0:01AM", "Today 0:01" and "Today 11:59PM" for exactly the same moment of time because method combines 2 values in non-thread safe way (even if each is thread safe on its own).

So to let you use such value in thread safe way authors of the library must take care of computing value in thread safe way (i.e. lock around).

Answer 6

Date.Now is thread safe because each time you need to get a value from the property a new DateTime is created, and given that all properties are created in the constructor and all properties are only get make it thread safe. Simply speaking it's immutable

DateTime.Now look like this

[__DynamicallyInvokable]
    public static DateTime Now
    {
      [__DynamicallyInvokable] get
      {
        DateTime utcNow = DateTime.UtcNow;
        bool isAmbiguousLocalDst = false;
        long ticks1 = TimeZoneInfo.GetDateTimeNowUtcOffsetFromUtc(utcNow, out isAmbiguousLocalDst).Ticks;
        long ticks2 = utcNow.Ticks + ticks1;
        if (ticks2 > 3155378975999999999L)
          return new DateTime(3155378975999999999L, DateTimeKind.Local);
        if (ticks2 < 0L)
          return new DateTime(0L, DateTimeKind.Local);
        else
          return new DateTime(ticks2, DateTimeKind.Local, isAmbiguousLocalDst);
      }
    }

Answer 7

What does MSDN actually flag as a problem? DateTime.Now property is implemented in such a way that it depends on "global" state: Have a look at TimeZoneInfo.s_cachedData, it's accessed from GetDateTimeNowUtcOffsetFromUtc().

Here's how it can get you into trouble After one CPU core changes the static value in response to a system event of time zone change, a stale cache line on another core would be accessed by DateTime.Now and would produce an incorrect time value, potentially differering by hours from the expected value since the static access is not protected by a sync object.

To fix things you could rely on DateTime.UtcNow, and figure out time zone information as a separate exercise, then smash them together. However, I fear that for the most frequently-used case, this would be overkill. Time zone offsets just don't change that often, (for example, only twice a year where I live).

Comparison with other languages: The signature of the property does not declare that there is a side-effect that can affect correctness of the returned result. In Haskell, for example, they would return an IO monad of DateTime, instead of DateTime. As another insight, look at the way hardware registers are commonly accessed in C++ by using keyword volatile. The keyword ensures the cache lines in the CPU that store the value are correctly refreshed on each access.