使用 Interlocked 进行线程安全的日期时间更新。*

Question

我可以使用 Interlocked.* 同步方法来更新 DateTime 变量吗？

我希望在内存中保留最后一次接触的时间戳。多个http线程将更新最后一个触摸DateTime变量。

我很欣赏 DateTime 变量是被替换而不是更新的值类型。

我能想到的最好的方法是将时间戳保存为很长一段时间内的总滴答数

class x
{
  long _lastHit;

  void Touch()
  {
    Interlocked.Exchange(ref _lastHit, DateTime.Now.Ticks);
  }
}

Answer 1

选项 1：使用 long 与 Interlocked 和 DateTime.ToBinary()。这不需要易失性（事实上，如果有它，您会收到警告），因为 Interlocked 已经确保了原子更新。您可以通过这种方式获得 DateTime 的准确值。

long _lastHit;

void Touch()
{
    Interlocked.Exchange(ref _lastHit, DateTime.Now.ToBinary());
}

要以原子方式读取此内容：

DateTime GetLastHit()
{
    long lastHit = Interlocked.CompareExchange(ref _lastHit, 0, 0);
    return DateTime.FromBinary(lastHit);
}

这将返回 _lastHit 的值，如果它是 0，则将其与 0 交换（即除了以原子方式读取该值之外，不执行任何操作）。

简单地读取是不行的 - 至少因为变量没有标记为易失性，因此后续读取可能只是重用缓存的值。结合挥发性和互锁可能在这里工作（我不完全确定，但我认为即使另一个核心执行非互锁读取，也无法在不一致的状态下看到互锁写入）。但如果您这样做，您将收到警告和组合两种不同技术的代码味道。

选项 2：使用锁。在这种情况下不太理想，因为互锁方法在这种情况下性能更高。但是您可以存储正确的类型，并且稍微清楚一点：

DateTime _lastHit;
object _lock = new object();

void Touch()
{
    lock (_lock)
        _lastHit = DateTime.Now;
}

您也必须使用锁来读取此值！顺便说一句，除了互斥之外，锁还可以确保无法看到缓存的值并且无法重新排序读/写。

非选项：什么都不做（只写值），无论您是否将其标记为易失性。这是错误的 - 即使您从未读取过该值，您在 32 位机器上的写入也可能会以一种不幸的方式交错，从而导致您得到损坏的值：

Thread1: writes dword 1 of value 1
Thread2: writes dword 1 of value 2
Thread2: writes dword 2 of value 2
Thread1: writes dword 2 of value 1

Result: dword 1 is for value 2, while dword 2 is for value 1

Answer 2

是的，你可以这样做。您最大的问题可能是 DateTime.Ticks 的分辨率只有 ~20 毫秒。因此，保留 DateTime last 或 longticks 变量并不重要。但由于 Exchange 没有对 DateTime 进行重载，因此您需要使用 long。

Answer 3

使用新的 Unsafe 类，终于可以直接在 DateTime 字段上使用：

public static DateTime InterlockedCompareExchange(ref DateTime location1, DateTime value, DateTime comparand)
{
    var storedAsLong = Interlocked.CompareExchange(ref Unsafe.As<DateTime, long>(ref location1),
                                                   value: Unsafe.As<DateTime, long>(ref value),
                                                   comparand: Unsafe.As<DateTime, long>(ref comparand));

    return Unsafe.As<long, DateTime>(ref storedAsLong);
}

备注（警告）：这里的等式与 DateTime 的常规等式不同：

• 常规 DateTime 等式: (日期时间 x, 日期时间 y) => x.Ticks == y.Ticks;
• 这里相等：(DateTime x, DateTime y) =>; x.Ticks == y.Ticks && x.Kind == y.Kind;

这里的相等性比较了 DateTime 的所有位，常规的忽略了专用于 Kind 的位。

Answer 4

编辑：基于@romkyns 的以下评论[谢谢]

如果您的代码在 32 位计算机上运行。那么 64 位长的数据将通过两个原子操作写入内存，可以被上下文切换中断。
所以一般来说你确实需要处理这个问题。

但要明确的是，对于这个特定的场景，（写一个代表时间滴答的长值）可以说这个问题是如此非常不值得处理......因为（除了每 2^32 滴答一次的瞬间），无论如何，任何两个并发写入的高位字（32 位）中的值都将相同......即使在极不可能的情况下，< /em> 跨越该边界的两个并发写入，它们同时互相中断，您从一个获得高字，从另一个获得低字，除非您也每毫秒读取该值，否则下一次写入无论如何都会解决问题，并且不会造成任何伤害。然而，采用这种方法，无论坏情况发生的可能性有多大，仍然允许出现极其微小但可能的情况，即每 40 亿个时钟周期中就会出现一次错误的值......（祝您尝试重现该错误好运...）

如果您在 64 位机器上运行，otoh（此时更有可能，但不保证），则 64 位内存插槽中的值将被原子写入，并且这里你不需要担心并发问题。仅当某些程序不变量在某些处理块期间处于无效状态时，才会发生竞争条件（这是您试图阻止的情况）被另一个线程中断。如果您所做的只是写入 lastTouch DateTime 变量（内存位置），那么就没有需要关心的 invlaid 不变量，因此您无需担心并发访问。

Answer 5

我的方法不是最好的方法之一，但是您可以使用字符串 var 来存储格式化的日期，然后将其解析回 datetime:

class x
{
  string _lastHit;

  void Touch()
  {
    Interlocked.Exchange( ref _lastHit, DateTime.Now.ToString("format your date") );   
  }
}

当您需要使用此值时，只需解析为 DateTime:

DateTime.Parse(_lastHit)

解析始终有效，因为字符串使用 DateTime 类进行格式化，但您可以使用 TryParse 来处理可能的解析错误