定时器和多线程的不同

时间:2021-08-19 03:58:55

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