Re: [asio-users] cpu usage of the asio::deadline_timer

[Christopher K. <ch...@ko...>]

Hi Boris,

--- godot <mo...@gm...> wrote:

> Hi,
> I have a question concerning the cpu usage of the
> asio::deadline_timer.
> Consider this sample code:
> 
> void restart( asio::deadline_timer* t )
> {
>    std::cout << "restart" << std::endl;
>    t->expires_at( t->expires_at() + boost::posix_time::seconds( 1 ));
>    t->async_wait( boost::bind( restart, t ));  
> }
> 
> int main()
> {
>   asio::demuxer d;
>   asio::deadline_timer t(d, boost::posix_time::seconds( 1 ));
>   t.async_wait( boost::bind( restart, &t ));
>   d.run(); 
>   return 0;
> }
> 
> 
> I'm using asio 0.3.6. and vc.net. It consumes 2% processor time while
> running when compiled in release mode, quite a lot for a mostly idle
> application, I think. Is it because the timer is so "fine-grained" in
> time? If I do not need a high performance timer, is it possible to
> finetune the timer setting, so that my application does not keeps the
> processor that busy?

I suspect that the problem is due to the timeout granularity on the
Windows implementation of select(). It appears that a very short
timeout (<10 milliseconds?) makes select() return immediately. If the
current time is very close to the timer expiry, this immediate return
might cause the select reactor to spin (thus accounting for the CPU
usage you observe) until the timer expiry is reached.

Can you please try the following change to see if it makes a
difference:

RCS file: /cvsroot/asio/asio/include/asio/detail/socket_ops.hpp,v
retrieving revision 1.36
diff -u -r1.36 socket_ops.hpp
--- include/asio/detail/socket_ops.hpp  23 Feb 2006 12:31:08 -0000     
1.36
+++ include/asio/detail/socket_ops.hpp  27 Feb 2006 11:38:06 -0000
@@ -466,6 +466,9 @@
     ::Sleep(milliseconds);
     return 0;
   }
+  if (timeout && timeout->tv_sec == 0
+      && timeout->tv_usec > 0 && timeout->tv_usec < 10000)
+    timeout->tv_usec = 10000;
 #endif // defined(BOOST_WINDOWS)
   return error_wrapper(::select(nfds, readfds, writefds, exceptfds,
timeout));
 }

I'm not sure if this is the best solution, but at least it will help
determine if this is in fact the cause of the bug you observe.

Cheers,
Chris