最近在做项目的时候，遇到了视频采集图像时。使用定时器与或使用多线程有些纠结。原先用了定时器测试了，因为项目需要占用较多的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条线程同步一般就能把人折腾死。同步我比较喜欢用临界区，原因也很简单：因为临界区比较简单…… /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// 1.软件开发当中经常需要用到这两个好东东，但是两个使用起来是有很大区别的哦， 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线程来插入代码，还是老老实实的发消息吧。 |