Volatile DateTime

Question

As DateTime cannot be declared as volatile, is this right?

private DateTime _time;
public DateTime Time
{
    get
    {
        Thread.MemoryBarrier();
        return _time;
    }
    set
    {
        _time = value;
        Thread.MemoryBarrier();
    }
}

That property could be accessed from different threads, so I want to ensure they get always the latest version, without use contention (lock).

EDIT:

• I have a collection of hard-to-create items, each one has a DateTime property named CreationTime, indicating when this item was created. It's initialized to DateTime.UtcNow.
• Every time a item is accessed, that property is updated to DateTime.UtcNow.
• There is a thread, that executes in timely fashion in a threaded timer that checks if (DateTime.UtcNow + 1 hour) > item.CreationTime, if true it deletes the item.

I want to ensure that when the "deletion thread" comes into the collection, all the items have their latest "last access" DateTime on it, so I can avoid create the item again just because a cache held the value for a couple of milliseconds. :D

Answer 1

Precisely.

But, you have another option. Store the time as an Int64 tick count, and use InterlockedExchange to set. Threads can then construct their own DateTime using The Int64 constructor, giving you no contention and no locks.

EDIT:

Given that you've provided more information, it's easier now to provide an example.

public class Cache
{
    class CacheEntry
    {
        private Int64 m_Touched;

        public CacheEntry()
        {
            Touch();
        }

        public void Touch() 
        {
            System.Threading.Interlocked.Exchange(ref m_Touched, DateTime.Now.Ticks);
        }

        public DateTime Touched
        {
            get
            {
                return new DateTime(Interlocked.Read(ref m_Touched));
            }
        }
    } // eo class CacheEntry
} // eo class Cache

Answer 2

This is not possible - you will need to use lock or the Monitor class to synchronize access to the field.

This is because DateTime is a value type - a structure.

From MSDN - volatile (C# Reference):

The volatile keyword can be applied to fields of these types:

• Reference types.
• Pointer types (in an unsafe context). Note that although the pointer itself can be volatile, the object that it points to cannot. In other words, you cannot declare a "pointer to volatile."
• Types such as sbyte, byte, short, ushort, int, uint, char, float, and bool.
• An enum type with one of the following base types: byte, sbyte, short, ushort, int, or uint.
• Generic type parameters known to be reference types.
• IntPtr and UIntPtr.

---

As others have mentioned, you can use Ticks to track time.

Answer 3

Your code isn't thread-safe since the assignment of DateTime isn't guaranteed to be atomic. In general assignments of integers up to 32bits are atomic, but 64 needn't be atomic.

You probably can use Interlocked.Exchange with the ticks of the DateTime since that can atomically store an Int64.

But if you switch to ticks you need to know that only 62 bits are used for the ticks, and 2 bits for the kind. So you don't lose the kind.

And even if you make the getter and setter atomic an threadsafe, I'm not sure if that's enough. Since the time can change between the time where your getter returns and the time you actually work with the time you got. So your time can always be outdated.

Answer 4

The .NET Core includes the Unsafe.As method, which allows to perform a volatile read/write on a DateTime variable like this:

public static DateTime VolatileRead(ref DateTime location)
{
    ref ulong unsafeLocation = ref Unsafe.As<DateTime, ulong>(ref location);
    ulong result = Volatile.Read(ref unsafeLocation);
    return Unsafe.As<ulong, DateTime>(ref result);
}

public static void VolatileWrite(ref DateTime location, DateTime value)
{
    ref ulong unsafeLocation = ref Unsafe.As<DateTime, ulong>(ref location);
    ref ulong unsafeValue = ref Unsafe.As<DateTime, ulong>(ref value);
    Volatile.Write(ref unsafeLocation, unsafeValue);
}

Usage:

DateTime latest = VolatileRead(ref _dateTimeField);

VolatileWrite(ref _dateTimeField, newDateTime);

This is a hack, as it depends on the DateTime type being backed by a ulong field forever. Use your own judgement whether it's appropriate/safe/prudent to use it, in a case-by-case basis.

From the source code of the DateTime struct:

private readonly ulong _dateData;