我看了“windows程序设计”中关于定时器的描述。书中说定时器也是消息出发,并且不是异步的。那是不是说OnTimer中处理的过程独占整个主线程呢?也就是说定时器的作用是在主线程的执行路径近似中等间隔的插入处理过程。这样的话定时器的触发和主线程的执行都可能相互影响。
  
   但是,如果某个间隔为一秒的定时器在OnTimer中需要处理的时间多于一秒,那么应该会出现这段处理过程的重复执行,那么要不要考虑数据的同步呢?
   
   请高手执教,谢谢。

解决方案 »

  1.   

    那是不是说OnTimer中处理的过程独占整个主线程呢?
    是的,定时器虽然看似不受主线程阻塞的影响,其实它还是在主线程中,并没有开另外的线程。(但是同样也存在线程被切换的现象。)如果某个间隔为一秒的定时器在OnTimer中需要处理的时间多于一秒,那么应该会出现这段处理过程的重复执行,那么要不要考虑数据的同步呢?
    要的
      

  2.   

    如果某个间隔为一秒的定时器在OnTimer中需要处理的时间多于一秒,那么应该会出现这段处理过程的重复执行,那么要不要考虑数据的同步呢?
    要的
    __________不同意。虽然是同一线程中的插入操作,但是也要等函数返回才能插入。
      

  3.   

    如果某个间隔为一秒的定时器在OnTimer中需要处理的时间多于一秒,那么应该会出现这段处理过程的重复执行,那么要不要考虑数据的同步呢?
    要的
    __________不同意。虽然是同一线程中的插入操作,但是也要等函数返回才能插入。
    ---------------------------------我比较赞同这个观点,既然都是在同一个线程,应该不会出现竞争。
      

  4.   

    WM_TIMER消息会被忽略,如果一个WM_TIMER消息正在处理,新的WM_TIMER消息不会产生,因此不存在函数重入的问题。类似的还有WM_PAINT消息。
      

  5.   

    试过,的确如 pomelowu(羽战士) 和 Mackz(在相互) 所说,不会重入。
    Mackz 也给出了令人信服的理由:如果一个WM_TIMER消息正在处理,新的WM_TIMER消息不会产生。
      

  6.   

    不会重入是确定的,但WM_TIMER真的不会产生吗?我的印像中当debug ontimer时,当一次ontimer中断了一段时间(debug)再F5通过后,会连续有若干个ontimer被执行
    从感觉上timer消息是被触发了的并加上了消息对列(但这个时候并没有去取这个消息,所以当然不会重入),当然,也可能是某种机制使得一个超时的ontimer结束后,立即产生一个timer消息到消息对列
      

  7.   

    同上。WM_TIMER是会产生的,不过如果多个相同WM_TIMER排在一起,会被合并。
    另,WM_TIMER的优先度是最低的。
      

  8.   

    如果某个间隔为一秒的定时器在OnTimer中需要处理的时间多于一秒,那么应该会出现这段处理过程的重复执行,那么要不要考虑数据的同步呢?
    ========================================================================================定时器的定时事件是不会累积的。即:如果规定的时间达到,而定时处理函数还没有执行,那么会从消息队列里面移除这个定时的消息的。
      

  9.   

    wltg2001(红猪) 
    ===========================
    NO, 在主消息循环里面消息不是同步处理的。而是分派消息(::DispatchMessage),分派完毕,即取下一消息,分派就是直接指定一个处理消息的对象或接受者,所以,消息处理并不需要等待。