定时器和多线程的不同

最近在做项目的时候，遇到了视频采集图像时。使用定时器与或使用多线程有些纠结。原先用了定时器测试了，因为项目需要占用较多的cpu，所以很明显图像显示比较卡。

所以网上查了下。贴出来大家学习学习。

软件定时器和多线程在控制工程中有着非常广泛的使用，主要是因为在控制过程中，会出现大量的Socket通信和串口通信数据量，仔细想了想，觉得这两样东西还是有比较的价值的，很多初学者（我也是。。。）可能会在这两样东西上困惑，现简单比较一下。

       首先注意： 线程消息队列中WM_PAINT，WM_TIMER只有在Queue中没有其他消息的时候才会被处理，WM_PAINT消息还会被合并以提高效率。其他所有消息以先进先出（FIFO）的方式被处理。http://zhidao.baidu.com/question/176892832.html?fr=ala0。

1 软件定时器

很多同学在工程中喜欢使用软件定时器，因为其使用简单，仅需设置一个时长和其OnTime事件即可使用。确实，软件定时器在某些持续性不强的重复性工作中效率还是不错的，但是也有着很大的缺点。

缺点1，速度：软件定时器的精度比较低，这是由Windows不实时的特性所决定的，在XP下，如果关闭所有能关闭的进程，MFC的软件定时器可以达到接近15ms的精度，而在Win2000下，其能达到接近10ms的精度。但是实际情况是，有些进程是不可以关闭的，比如说数据库服务器，所以MFC的软件定时器能够达到的精度一般情况下在40ms左右，BCB和delphi就更差一点，大概在55ms左右。QueryPerformanceCounter倒是可以大幅提高精度，但是稳定性欠佳。

缺点2，效率：软件定时器其本质实际上是在消息循环中处理WM_TIMER消息，而WM_TIMER消息在消息队列中是一个低级别的消息，所以定时器并不能完全保证处理时间间隔的准确性。另外，Timer占用的是主线程的资源，看似并行实际上是串行，所以窗体的消息队列一旦堵塞，就会造成系统假死或者运行缓慢，这对于UI来说几乎是无法忍受的。

2 多线程

多线程技术是在控制工程中常用的技术，因为在闭环系统中有着大量的数据处理，这些处理显然不可能放在主线程中处理，绝大多数都是在线程中使用。多线程的优点比较明显，就是把费劲的东西扔到后台去，而且对CPU的利用率比较高。如果控制的好，多线程几乎是没有什么缺点的，但实际上控制的好的并不多……原因如下：

1、时间片不可控，抢CPU资源的事情~一般人说不清；

2、同步比较复杂，容易发生死锁，3条线程同步一般就能把人折腾死。同步我比较喜欢用临界区，原因也很简单：因为临界区比较简单……

http://cache.baidu.com/c?m=9f65cb4a8c8507ed4fece7631046893b4c4380146d96864968d4e414c422461e4d6ce4be2329171980852d3d5aeb1e41eaf235702a0125aa99cd954dd8b8992e2a883034074fc70358c75cf28b102ad650944d9aa50e96c9e74290b9d3a3c82557dd27006d81809c2a7303bb19e71541f4d7ed5f632b07caec27148e4e7659885347a136fff7331e10f0f3ca2846d45ad3766595&p=8b2a9204809b1fb906bd9b7f0d57&user=baidu

///

1.软件开发当中经常需要用到这两个好东东，但是两个使用起来是有很大区别的哦，
　　如果在PC上可能效果差不多，如果放到CE小手持设备可能就很明显的感觉得到；
　　如果是定时器，如果是在有界面处理的APP中，你会感觉到程序在一顿一顿的；
　　当然，如果处理的东西本来就很少很少，用两者是没有感觉的，但是用在很大的
　　耗时处理上面，效果就出来了；
　　为什么呢？因为Timer来了优先级很高所以会先去处理定时器例程，如果处理很
　　耗时，那一定会一顿一顿的；
　　Thread就不同了，CE也是抢占式OS,多线程时是时间轮片处理的；所以如果用线程
　　的话也可以达到定时器的效果，并且不会感觉到一顿一顿的BUG;因为无论你的处理
　　有多耗时，时间片一到就又去处理别的了；如果处理的内容很独立，没有与其他
　　线程有耦合的话，是可以这样做的；

2.

 

　SetTimer函数和WM_TIMER消息是Win32 api中最基本的玩意儿了，任何初学Win32 api编程的人都应该对此很熟悉吧。在这篇文章中，让我们来深入了解一下和SetTimer相关的使用和应用。

　　UINT_PTR SetTimer(

　　HWND hWnd,

　　UINT_PTR nIDEvent,

　　UINT uElapse,

　　TIMERPROC lpTimerFunc

　　);

　　我们经常使用的情况是hWnd不为NULL，lpTimerFunc为NULL，在这种情况下系统每隔nIDEvent毫秒会向hWnd窗口投递WM_TIMER消息。唯一需要注意的是：

　　1.自2000起，uElapse范围是USER_TIMER_MINIMUM到USER_TIMER_MAXIMUM。超出得话，uElapse设置为1。

　　2.WM_TIMER消息其实是在DispatchMessage函数中直接调用hWnd的窗口过程，并且优先级很低，只有在消息队列中没有其它消息的情况下，DispatchMessage才会考虑WM_TIMER。

　　3.使用相同的nIDEvent可以重置这个Timer，并且KillTimer(hWnd,nIDEvent)来销毁这个Timer。

　　我们再来考虑hWnd为NULL的情况：

　　1.首先，最重要的是KillTimer时，传入的Timer Id必须是SetTimer的返回值，而不是调用SetTimer时传入的nIDEvent参数。

　　2.调用SetTimer时，如果nIDEvent为0或者是其它没有被使用的Timer Id，则SetTimer会返回一个新的Timer Id。否则，就是重新设置这个Timer。

　　3.如果有lpTimerFunc的话，则lpTimerFunc的参数nIDEvent是SetTimer返回的值，而不是你调用SetTimer时传入的值。

　　最后看一下lpTimerFunc不为NULL的情况：lpTimerFunc会在DispatchMessage函数中被直接调用，而不会去调用hWnd的窗口过程（也就是说收不到这个消息），无论hWnd是不是NULL。（这里，msdn中貌似有点问题，SetTimer的Remark部分说lpTimerFunc会在默认窗口中被调用，而WM_TIMER中说lpTimerFunc在DispatchMessage中被调用）

　　应用

　　使用lpTimerFunc可以做一个延时的操作，或者把某些操作推迟到下一个消息循环，而不需要为窗口定义一个新的Timer Id。

　　例如，我很喜欢这样写：

　　struct _DATA

　　{

　　//....

　　};

　　void CALLBACK TimerProc(HWND hwnd,

　　UINT uMsg,

　　UINT_PTR idEvent,

　　DWORD dwTime)

　　{

　　_DATA * data = (_DATA*)idEvent;

　　KillTimer(hwnd,idEvent);

　　//do something

　　free(data);

　　}

　　_DATA * data = (_DATA*)malloc(sizeof(_DATA));

　　SetTimer(AfxGetMainWindow()->m_hWnd,(UINT_PTR)data,10,&TimerProc);

　　首先，使用了TimerProc，不会使窗口收到WM_TIMER消息，那样可以使用idEvent来传递自定义数据而不会和窗口自己使用的Timer id冲突。

　　其次，第一个参数hWnd不能为NULL，否则TimerProc的idEvent参数就不是你传入的自定义数据了。

　　最后，msdn说SetTimer不能跨线程使用，所以最好不要用这样的方法在向ui线程来插入代码，还是老老实实的发消息吧。