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

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.