C#计时器在间隔时间之前被解雇

Swa*_*sas 12 .net c# events timer

System.Threading.Timer从Windows服务使用(.NET 2.0)时,我们遇到了以下问题.

  1. 有大约12个不同的计时器对象..
  2. 每个计时器都有适当的时间和间隔.这是正确设置的.
  3. 观察到在3到4小时后,定时器在它们的间隔过去之前开始发信号.例如,如果计时器应该在4:59:59发出信号,它会在7秒前的4:59:52发出信号.

有人能告诉我这种行为的原因是什么,解决方案是什么?

谢谢,斯瓦蒂

Tim*_*uri 10

好问题......这就是原因:

对于计算机而言,"时间安排"是一个棘手的问题......你永远不能依靠"间隔"来完美.有些计算机只会每隔14到15毫秒"打勾"一次计时器,有些计算机会比这更频繁,有些则不那么频繁.

所以:

Thread.Sleep(1);
Run Code Online (Sandbox Code Playgroud)

可能需要1到30毫秒才能运行.

相反,如果你需要一个更精确的计时器 - 你必须捕获开始时的DateTime,然后在你的计时器中你必须通过减去DateTime.Now和你的原始时间来检查它是否是"运行时间"你的代码.

以下是您需要做的一些示例代码:

DateTime startDate = DateTime.Now;
Run Code Online (Sandbox Code Playgroud)

然后,以1毫秒的间隔启动计时器.然后,在您的方法中:

if (DateTime.Now.Subtract(startDate).TotalSeconds % 3 == 0)
{
    // This code will fire every 3 seconds.
}
Run Code Online (Sandbox Code Playgroud)

上面的代码将每3秒忠实地发射一次.你可以让它运行10年,它仍然会每3秒发射一次.


Han*_*ant 8

Timothy的解释引人注目,但System.Threading.Timer已经以这种方式工作.至少在Rotor实现中,它使用GetTickCount()返回的值来计算下一个回调到期的时间.真正的CLR也不太可能这样做,它更可能使用CreateTimerQueueTimer().然而,这个API函数也可能取决于由时钟节拍中断增加的内部节拍.

问题在于内部时钟滴答(由GetTickCount()和Environment.TickCount返回)与绝对挂起时间保持同步(由DateTime.Now返回).不幸的是,这是您机器上硬件抽象层的HAL的实现细节.机器制造商可以提供自定义HAL,这个HAL经过调整后可以与机器的BIOS和芯片组配合使用.

如果机器有两个定时源,一个设计用于跟踪墙壁时间的时钟芯片,即使你拔掉机器电源也能保持滴答声,以及芯片组上可用的另一个频率可用于提供时钟中断.最初的IBM AT PC以这种方式工作.时钟芯片通常可以信任,如果不准确,时钟会严重关闭.芯片组不能,削减振荡器的质量是一个节省一分钱的简单方法.

通过避免计时器上的长时间段并从回调中的DateTime.Now重新计算下一个到期时间来解决您的问题.


the*_*ost 0

也许在需要几秒钟才能完成的操作之后会完成重新调度。或者你不控制这个?