c# - "Atomically"更改 System.Threading.Timer

Question

假设我有一个现有的 System.Threading.Timer 实例，我想对其调用 Change 以将其触发时间后移:

var timer = new Timer(DelayCallback, null, 10000, Timeout.Infinite);
// ... (sometime later but before DelayCallback has executed)
timer.Change(20000, Timeout.Infinite);

我正在使用这个计时器在一段时间没有事件后执行“空闲回调”。 (在这种情况下，“空闲”和“无事件”是应用程序定义的条件……具体细节并不是非常重要。)每次执行“操作”时，我都想重置计时器，以便始终设置10 秒后开火。

但是，存在一个固有的竞争条件，因为当我调用 Change 时，我无法根据其旧设置判断 Timer 是否已经触发。 (当然，我可以判断我的回调是否已经发生，但我无法判断 CLR 的内部计时器线程是否已将我的回调排队到线程池并且它的执行迫在眉睫。)

现在我知道我可以在计时器实例上调用 Dispose 并在每次需要“将其推回”时重新创建它。但这似乎不如仅仅更改现有计时器有效。当然，可能不是...我稍后会运行一些微基准测试，然后让大家知道。

或者，我可以始终跟踪预期的触发时间(通过 DateTime.Now.AddSeconds(10))，如果原始 Timer 触发，则通过在回调中检查 DateTime.Now 来忽略它。 (我一直担心这可能不是 100% 可靠的，因为 Timer 使用 TimeSpan 和我使用 DateTime 进行检查……这可能不是问题，但出于某种原因我并不完全满意…… )

我的问题是:

1. 有没有一种好方法可以让我调用 Timer.Change 并能够在回调排队到线程池之前知道我是否设法更改了它？ (我不这么认为，但问问也无妨……)
2. 有没有其他人实现(我称之为)这样的“回推计时器”？如果是这样，我很想听听您是如何解决这个问题的。

这个问题本质上有点假设性，因为我已经有几个可行的解决方案(基于 Dispose 和基于 DateTime.Now)...我主要对听取与性能相关的建议感兴趣(因为我会非常频繁地“推回”计时器)。

谢谢!

Answer 1

听起来您真正想要的是应用程序空闲事件

System.Windows.Forms.Application.Idle