定时器和多线程的不同

 最近在做项目的时候，遇到了视频采集图像时。使用定时器与或使用多线程有些纠结。原先用了定时器测试了，因为项目需要占用较多的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线程来插入代码，还是老老实实的发消息吧。