windows定时器的总结

windows定时器的总结

  (2011-09-20 10:44:09)

标签：  杂谈

分类： c#方面的总结

定时器的总结

昨天突然遇到定时器到底是如何实现的这个问题，一个本来很浅显的东西，立刻变得含混起来，回家查了LINXU内核的定时器实现机制，非但没有弄清楚，倒好，更糊涂了。
在LINUX下，使用了硬件计时器进行时钟中断，和软件插值的方法实现，其中的区别很大，而且硬件中断也有几种方法，这里咱们先不弄LINUX下的，回头有时间我会整理一下。先讲一下WINDOWS下的定时器的原理，我们不讲使用，使用的方法MSDN和网上都滥了。
经过这两天的仔细查看MSDN和网络资料，个人认为WINDOWS下的定时器可以分三种，即在MSDN中的系统服务、线程、UI。其实这是在NET上才实现的。我个人认为在NET前的使用上根本就是只有一种，即UI。不管你是不是有UI，其实实现的方法都是用UI的方法实现的。至于WINDOWS内部如何操作硬件，这个我们不做深入了解，也没有必要。即使你天天做驱动，估计深入了解这个东西的作用也没有太大，当然，如果你给微软写或修改这部分代码就另外算了。

MSDN上说，前两种，使用 TimerCallback 委托指定希望 Timer 执行的方法。计时器委托在构造计时器时指定，并且不能更改。此方法不在创建计时器的线程上执行，而是在系统提供的 ThreadPool 线程上执行。这个清楚明白的说明了，定时器是在多线程上执行的，但UI计时器则不同，Timer 用于以用户定义的事件间隔触发事件。Windows 计时器是为单线程环境设计的，其中，UI 线程用于执行处理。它要求用户代码有一个可用的 UI 消息泵，而且总是在同一个线程中操作，或者将调用封送到另一个线程。
Windows 窗体 Timer 组件是单线程组件，精度限定为 55 毫秒。如果您需要更高精度的多线程计时器，请使用 System.Timers 命名空间中的 Timer 类。
上面都是MSDN上的原话，大家可以自己看。

而且在网上找到了一个说明测试的方法及错误改正的原理，非常有意思：
问：
a、MessageBox对话框在点击之前，主线程就应该停止了，
b、默认不在主线程中修改界面，会报错；

如果以上正确，为什么出现以下问题 ，
由timer显示的对话框，显示后 主线程停止了，但其到时间还会弹出对话框；在timer里修改界面不报错。
1、timer 调用的内容和主线程什么关系？
2、timer是不是多线程？timer是什么原理？
3、会不会前一次timer没处理完，后一次timer开始工作？  //最重要
4、System.Windows.Forms.Timer和其他timer各有什么？给个链接就行
答：
hi 搂住，您正好用了Messagebox来测试，如果您用大型计算（for循环10亿次）或让线程Sleep那么您就会发现是一个一个timer事件来顺序执行。所以问题应该出在Messagebox上。

    通过调试窗口的“调用堆栈”和“寄存器”来监视，当ontick事件中没有Messagebox时，只会有一个ontick堆栈。而且是按时间顺序一个接一个运行。

    而当ontick事件中有Messagebox时，则，调用堆栈一直增加，除非您点击“确定”，才会返回。我猜测这是 windows的消息机制的体现。system.windows.forms.timer是通过往窗体上发WM_TIME。估计Messagebox并非 真正意义上阻塞主窗口线程，当我追踪到底层时，发现Messagebox已通过SafeNativeMethods开始调用外部的COM了，很有可能在这 交出了主窗口线程的控制权。从而使得第二个Messagebox得以触发。根据堆栈的观测，当对第二个Messagebox点确定时，会返回第二个ontick的堆栈。并且阻塞窗口线程。点击确定后，执行完毕又会回到第一

个timer ontick事件的堆栈。最终执行完毕。

   当不用timer，而是直接在代码中用Messagebox,则会等待确定，看起来像是阻塞了线程，个人估计Messagebox没有阻塞主窗口线程，而 是阻止了消息发送到主窗口线程，所以感觉上是阻塞线程。而Timer则是内核发送WM_TIME，不会被Messagebox阻止。

 

下面再转一篇别人的博客：

定时器：.NET框架类库中定时器类的比较

原著：Alex Calvo

翻译：lxhui

原文出处：MSDN Magazine February 2004(Timer...)

原代码下载: TimersinNET.exe (126KB)

本文章假定你熟悉C#

 概要  

　　不论在客户端应用程序还是服务器组件（包括窗口服务）定时器通常扮演一个重要的角色。写一 个高效的定时器驱动型可管理代码要求对程序流程有一个清晰的理解及掌握.NET线程模型的精妙之处。.NET框架类库提供了三种不同的定时器 类：System.Windows.Forms.Timer, System.Timers.Timer, 和System.Threading.Timer。每个类为不同的场合进行设计和优化。本文章将研究这三个类并让你理解如何及何时应该使用哪一个类。

---

　　Microsoft® Windows®里的定时器对象当行为发生时允许你进行控制。定时器一些最常用的地方就是有规律的定时启动一个进程，在事件之间设置间隔，及当进行 图形工作时维护固定的动画速度（而不管处理函数的速度)。在过去，对于使用Visual Basic®的开发者来说，定时器甚至用来模拟多任务。

　　正如你所期望的那样，对于你需要应对的不同场合微软为你装备了一些工具。在.NET框架类 库中有三种不同的定时器类：System.Windows.Forms.Timer，System.Timers.Timer，和 System.Threading.Timer。头两个类出现在Visual Studio® .NET的工具箱窗口，这两个定时器控件都允许你直接把它们拖拽到Windows窗体设计器或组件类设计器上。如果你不小心，这就是麻烦的开始。

　　Visual Studio .NET工具箱上的Windows窗体页和组件页（见Figure 1）都有定时器控件。非常容易的错误地使用它们当中的一个，或者更糟糕的是，根本意识不到它们的不同。仅当目标是Windows窗体设计器时才使用 Windows窗体页上的定时器控件。这个控件将在你的窗体上放置一个Systems.Windows.Forms.Timer类的实例。像工具箱上的其 它控件一样，你可以让Visual Studio .NET处理其生成或者你自己手动的实例和初始化这个类。

　　Figure 1  定时器控件

　　在组件页上的定时器控件可以被安全的用在任何类中。这个控件创建了一个 System.Timers.Timer类的实例。如果你正在使用Visual Studio .NET工具箱，无论是Windows窗体设计器还是组件类设计器你都可以安全的使用这个类。在Visual Studio .NET中当你设计一个派生于System.ComponentModel.Component的类时使用组件类设计器。 System.Threading.Timer类不出现在Visual Studio .NET工具箱窗口上。它稍微有点复杂但提供了一个更高级别的控件，稍后你会在本文章中看到。

　　Figure 2  例子程序

　　让我们首先研究System.Windows.Forms.Timer和 System.Timers.Timer类。这两个类有着非常相似的对象模型。稍后我将探索更加高级的System.Threading.Timer类。 Figure 2 是我将在整个文章引用的例子程序的一个屏幕快照。这个应用程序将会让你获得对这几个定时器类的清晰的理解。你可以从本文章的开始链接处下载完整的代码并试 验它。

 System.Windows.Forms.Timer

　　如果你在找一个节拍器，你已经走错了地方了。这个定时器类引发的定时器事件是同你的窗口应 用程序的其余代码相同步的。这意味着正在执行的代码从来不会被这个定时器类的实例所抢占（假设你不调用Application.DoEvents）。就像 一个典型窗体程序里的其它代码一样，任何驻留在一个定时器事件处理函数（指的是该类型的定时器类）中的代码也是使用应用程序的UI线程所执行。在空闲时 候，该UI线程同样要对应用程序的窗体消息队列中的所有消息进行负责。这不仅包括由这个定时类引发的消息，也包括窗体API消息。无论何时你的程序不忙于 做其它事情时该UI线程就处理这些消息。

　　在Visual Studio .NET之前如果你写过Visual Basic代码，你可能知道在一个窗口应用程序里当正在执行一个事件处理函数时让你的UI线程去响应其它窗体消息的唯一方法就是调用 Application.DoEvents方法。就像Visual Basic一样，从.NET框架中调用Application.DoEvents能够产生许多问题。Application.DoEvents产生了对 UI消息泵的控制，让你对所有未处理的事件进行处理。这能够改变我刚才提到的所期望的执行路径。如果为了处理由该定时器类产生的定时器事件而在你的代码中 有一个Application.DoEvents的调用，你的程序流程可能会被打断。这会产生不希望的行为并使调试困难。

　　运行例子程序就会使这个定时器类的行为变得清楚。单击程序的Start按钮，接着单击Sleep按钮，最后单击Stop按钮，将会产生下面的输出结果：

System.Windows.Forms.Timer Started @ 4:09:28 PM--> Timer Event 1 @ 4:09:29 PM on Thread：UIThread--> Timer EVENT 2 @ 4:09:30 PM on Thread: UIThread--> Timer Event 3 @ 4:09:31 PM on Thread: UIThreadSleeping for 5000 ms...--> Timer Event 4 @ 4:09:36 PM on Thread: UIThreadSystem.Windows.Forms.Timer Stopped @ 4:09:37 PM　　例子程序设置System.Windows.Forms.Timer类的间隔属性为1000毫秒。正如你所看到的，当UI线程正在睡眠（5秒）期 间如果定时器事件处理函数仍然继续捕捉定时器事件的话，当睡眠线程再次被唤醒的时候应该有5个定时器事件被显示——在UI线程睡眠时每秒钟一个。然而，当 UI线程在睡眠时定时器却保持挂起状态。

　　对System.Windows.Forms.Timer的编程不能再简单了——它有一个 非常简单和可直接编程的接口。Start和Stop方法实际上提供了一个设置使能属性的改变方法（其本身是对Win32®的SetTimer和 KillTimer功能的一个包装）。我刚才提到的间隔属性，名字本身就说明了问题。即使技术上你可以设置间隔属性低到1毫秒，但你应该知道在.NET框 架文档中指出这个属性大约精确到55毫秒（假定UI线程对于处理是可用的）。

　　捕捉由System.Windows.Forms.Timer类实例引发的事件是通过感知一个标准的EventHandler委托的标记事件来处理的，就像下面的代码片断所示：

System.Windows.Forms.Timer tmrWindowsFormsTimer = new System.Windows.Forms.Timer();tmrWindowsFormsTimer.Interval = 1000;tmrWindowsFormsTimer.Tick += new EventHandler(tmrWindowsFormsTimer_Tick);tmrWindowsFormsTimer.Start();...private void tmrWindowsFormsTimer_Tick(object sender, System.EventArgs e){ //Do something on the UI thread...} System.Timers.Timer

　　.NET框架文档指出System.Timers.Timer类是一个服务器定时器，是为 多线程环境进行设计和优化。该定时器类的实例能够被多个线程安全地访问。不像 System.Windows.Forms.Timer，System.Timers.Timer缺省的，将在一个工作者线程上调用你的定时器事件处理函 数，该工作者线程是从公共语言运行时（CLR）线程池中获得。这意味着在你的逝去的时间处理函数代码中必须遵从Win32编程的黄金规则：除了创建该控件 实例的线程之外，一个控件的实例从来不被任何其它的线程所访问。

　　System.Timers.Timer提供了一个简单的方法处理这样的困境——暴露一个 公共的SynchronizingObject属性。把该属性设置为一个窗体实例（或者窗体上的一个控件）将保证你的事件处理函数代码运行在 SynchronizingObject被实例化的同一个线程里。

　　如果你使用了Visual Studio .NET工具箱，Visual Studio .NET自动的设置SynchronizingObject属性为当前的窗体实例。首先它设定该定时器的SynchronizingObject属性使其 在功能上同System.Windows.Forms.Timer类一样。对于大部分功能，的确是这样。当操作系统通知 System.Timers.Timer类所允许的定时时间已过去，定时器使用SynchronizingObject.Begin.Invoke方法在 一个线程上去执行事件委托，该线程是创建SynchronizingObject的线程。事件处理函数将被阻塞直到UI线程能够处理它。然而不像 System.Windows.Forms.Timer类一样，该事件最终仍然能够被引发。像你在Figure 2中看到的，当UI线程不能够处理时System.Windows.Forms.Timer不会引发事件，可是当UI线程可用时 System.Timers.Timer却会排队等候处理。

　　Figure 3是如何使用SynchronizingObject属性的例子。使用例子程序并通过选择System.Timers.Timer的radio按钮你可以分析这个类，并按照执行System.Windows.Forms.Timer类行为的同样顺序运行该类，这样就会产生Figure 4的输出结果。

　　正如你所看到的，它不会跳过一个跳动——即使UI线程在睡眠。在每一个事件间隔就有一个时间消失事件处理会被排队执行。因为UI线程在睡眠，所以当UI线程一旦被唤醒例子程序就会列出5个定时器事件（4到8）并能够处理处理函数。

　　正如我早先提到的，System.Timers.Timer类成员非常类似与 System.Windows.Forms.Timer。最大的区别就在与System.Timers.Timer类是对Win32可等待定时对象的一个 包装，并在工作者线程上产生一个时间片消失事件而不是在UI线程上产生一个时间标记事件。时间片消失事件必须与一个同 ElapsedEventHandler委托像匹配的事件处理函数相连接。事件处理函数接受一个ElapsedEventArgs类型的参数。

　　除了标准的EventArgs成员，ElapsedEventArgs类暴露了一个公共的 SignalTime属性，它包含了一个精确的定时器时间片消失的时间。因为这个类支持不同线程的访问，除了时间消失事件所在的线程，应该相信它的 Stop方法能够被其它线程所调用。这会潜在的导致消失事件被引发即使其Stop方法已经被调用。你可以把SignalTime和Stop方法调用的时间 进行比较来解决这个问题。

　　System.Timers.Timer也提供了AutoReset属性来决定当时间片消 失事件引发后是继续进行还是只这一次。要记住在定时器开始后重设间隔属性会导致当前计数为0。比如，设置了一个5秒的间隔，在间隔被改变为10秒时3秒已 经过去了，那么下一个定时器事件将会在上一个定时器事件13秒后发生。

 System.Threading.Timer

　　第三个定时器类来自System.Threading名字空间。我愿意说这是所有定时器类 中最好的一个，但这会引起误导。举一个例子，我惊讶的发现对于驻留在System.Threading名字空间的这个类天生就不是线程安全的。（很明显， 这不意味着它不能以线程安全的方式使用）。这个类的可编程接口同其它两个类也不一致，它稍微有点麻烦。

　　不像我开始描述的两个定时器类，System.Threading.Timer有四个重载构造函数，就像下面这样：

public Timer(TimerCallback callback, object state, long dueTime, long period);public Timer(TimerCallback callback, object state, UInt32 dueTime, UInt32 period);public Timer(TimerCallback callback, object state, int dueTime, int period);public Timer(TimerCallback callback, object state, TimeSpan dueTime, TimeSpan period);第一个参数（callback)要求一个TimerCallback的委托，它指向一个方法，该方法具有下面的结构：

public void TimerCallback(object state);第二个参数（state）可以为空或者是包含程序规范信息的对象。在每一个定时器事件被调用时该state对象作为一个参数传递给你的定时 回调函数。记住定时回调功能是在一个工作者线程上执行的，所以你必须确保访问state对象的线程安全。

第三个参数(dueTime)让你定义一个引发初始定时器事件的时间。你可指定一个0立即开始定时器或者阻止定时器自动的开始，你可以使用System.Threading.Timeout.Infinite常量。

第四个参数（period）让你定义一个回调函数被调用的时间间隔（毫秒）。给该参数定义一个0或者Timeout.Infinite可以阻止后续的定时器事件调用。

　　一旦构造函数被调用，你仍然可以通过Change方法改变dueTime和period。该方法有下面四种重载形式：

public bool Change(int dueTime, int period);public bool Change(uint dueTime, uint period);public bool Change(long dueTime, long period);public bool Change(TimeSpan dueTime, TimeSpan period);　　下面是我在例子程序中用到的开始和停止该定时器的代码：

//Initialize the timer to not start automatically...System.Threading.Timer tmrThreadingTimer = newSystem.Threading.Timer(new TimerCallback(tmrThreadingTimer_TimerCallback), null, System.Threading.Timeout.Infinite, 1000);//Manually start the timer...tmrThreadingTimer.Change(0, 1000);//Manually stop the timer...tmrThreadingTimer.Change(Timeout.Infinte, Timeout.Infinite);　　正如你所期望的那样，通过选择System.Threading.Timer类运行例子程序会产生同你看到的 System.Timers.Timer类一样的输出结果。因为TimerCallback功能也是在工作者线程上被调用，没有一个跳动被跳过（假设有工 作者线程可用）。Figure 5显示了例子程序的输出结果。

　　不像System.Timers.Timer类，没有与SynchronizingObject相对应的属性被提供。任何请求访问UI控件的操作都必须通过控件的Invoke或BeginInvoke方法被列集

 定时器的线程安全编程

　　为了最大限度的代码重用，三种不同类型的定时器事件都调用了同样的ShowTimerEventFired方法，下面就是三个定时器事件的处理函数：

private void tmrWindowsFormsTimer_Tick(object sender, System.EventArgs e){ ShowTimerEventFired(DateTime.Now, GetThreadName());}private void tmrTimersTimer_Elapsed(object sender, System.TimersElapsedEventArgs e){ ShowTimerEventFired(DateTime.Now, GetThreadName());}private void tmrThreadingTimer_TimerCallback(object state){ ShowTimerEventFired(DateTime.Now, GetThreadName());}　　正如你所看到的，ShowTimerEventFired方法采用当前时间和当前线程名字作为参数。为了区别工 作者线程和UI线程，在例子程序的主入口点设置CurrentThread对象的名字属性为"UIThread"。GetThreadName帮助函数返 回Thread.CurrentThread.Name值或者当Thread.CurrentThread.IsThreadPoolThread属性为 真时返回"WorkerThread"。

　　因为System.Timers.Timer和 System.Threading.Timer的定时器事件都是在工作者线程上执行的，所以在事件处理函数中的任何用户交互代码都不是马上进行的，而是被 列集等候返回到UI线程上进行处理。为了这样做，我创建了一个ShowTimerEventFiredDelegate委托调用：

private delegate void ShowTimerEventFiredDelegate (DateTime eventTime, string threadName);　　ShowTimerEventFiredDelegate允许ShowTimerEventFired方法在UI线程上调用 它自己，Figure 6显示了发生这一切的代码。

　　通过查询InvokeRequired属性可以非常容易的知道你是否从当前线程可以安全的 访问Windows窗体控件。在这个例子中，如果列表框的InvokeRequired属性为真，窗体的BeginInvoke方法就可以被 ShowTimerEventFired方法调用，然后再被ShowTimerEventFiredDelegate方法调用。这能够保证列表框的Add 方法在UI线程上执行。

　　正如你所看到的，当你编写异步定时器事件时有许多问题需要意识到。在使用System.Timers.Timer和System.Threading.Timer之前我推荐你阅读Ian Griffith的文章“Windows Forms:Give Your .NET-based Application a Fast and Responsive UI with Multiple Threads”， 该文刊登在MSDN杂志的2003年2月份的期刊上。

 处理定时器事件重入

　　当和异步定时器事件打交道时，如由System.Timers.Timer和 System.Threading.Timer产生的定时器事件，有另外一个细微之处你需要考虑。问题就是必须处理代码重入。如果你的定时器事件处理函数 代码执行时间比你的定时器引发定时器事件的时间间隔要长，你预先又没有采取必要的措施保护防止多线程访问你的对象和变量，你就会陷入调试的困境。看一下下 面的代码片断：

private int tickCounter = 0;private void tmrTimersTimer_Elapsed(object sender, System.Timers.ElapsedEventArgs e){ System.Threading.Interlocked.Increment(ref tickCounter); Thread.Sleep（5000）； MessageBox.Show(tickCounter.ToString());}　　假设你的定时器间隔属性设置为1000毫秒，你也许会奇怪当第 一个信息框弹出时显示的值是5。这是因为在这5秒期间第一个定时器事件正在睡眠，而定时器却在不同的工作者线程上继续产生时间消失事件。因此，在第一个定 时器事件处理完成之前tickCounter变量被增加了5次。注意我使用了Interlocked.Increment方法以线程安全的方式增加 tickCounter变量的值。也有其它方法可以这样做，但是Interlock.Increment是为这种操作而特别设计的。

　　解决这种问题的简单方法就是在你的事件处理函数代码块中暂时禁止定时器，接着再允许定时器，就像下面的代码：

private void tmrTimersTimer_Elapsed(object sender, System.Timers.ElapsedEventArgs e){ tmrTimers.Enabled = false; System.Threading.Interlocked.Increment(ref tickCounter）； Thread.Sleep(5000); MessageBox.Show(tickCounter.ToString()); tmrTimersTimer.Enabled = true;}　　有了这段代码，消息框就会每5秒钟显示一次，就像你所期望的那样，tickCounter的值每次只增加1。另外一些可选的原始同步对象 就是Monitor或mutex去确保所有将来的事件被排队直到当前的事件处理函数执行完成。

 结论

　　为了快速方便的看到.NET框架中这三个定时器类的不同之处，见Figure 7对三个类的比较。当使用定时器类时有一点你要考虑的就是是否可以使用Windows调度器去定期的运行标准的可执行程序来更简单的解决问题。

 作者简介

　　Alex Calvo 是微软认证的.NET解决方案开发者。当他不进行阅读，编码或思考时，他就弹吉他。Alex Calvo 的联系地址：acalvo@hotmail.com

---

 译者结束语

　　在翻译过程中一些术语、单词或词组总是找不到合适的汉语解释， 现已经将它们列入 MTT 术语表，希望大家能给出更好的解释：

1. Elapsed——消失，时间消失。意思就是指所设置的定时时间间隔过去了。在文中主要有Elapsed Event, Elapsed Event
2. handler, Elapsed timer等词。
3. toolbox——工具箱
4. windows tab——窗体页
5. component tab——组件页
6. handler——处理器，实际就是所说的函数或方法

学一个东西，当知其然，然后知其所以然，每天前进一点点，努力向上！！！！！！