Re: [boost] boost.timer library submission...
Do you hold a mutex locked while invoking a callback? yes, I'm holding a boost::unique_lock<boost::mutex>... as a result, the callback method shouldn't do much. Mine only records the fact that the timer fired and the data passed back and puts it on a queue for another of my app
Hi Dmitry, Answers in-line... threads to handle.
What mechanism do you use to suspend till it's time to fire a callback?
boost::condition_variable m_timed_cond.timed_wait(timer_lock, cur_timer)
What is the precision of your library? I mean if you instruct the library to invoke your callback in so many ms usually your callback will be invoked at bit later. The question is how long later? Or earlier?
Typically fires later than earlier... the tolerance window I've been using is 5 ms - 10ms. The unit test included in the lib I uploaded to boost value includes a test that puts 100 timers up and measures when they fire. Occassionally out of that window. So far I've been running this on my mac and there's a lot running on it typically, so I'm suspicious of my results and think they could be better.
Does the precision degrade when you register lots of callbacks?
Not that I know of... I've put a couple of hundred thousand in there... so far the time to rebalance the underlying map for insertion / deletion hasn't shown up as an effect.
What's the smallest possible timeout the library lets to register a callback with? How does the library handle small (e.g. 1 ms) timeout requests?
Currently, millisecond resolution but totally happy to change it to reflect the greatest accuracy the underlying system timer can achieve. I've been testing this with a timing window (i.e., anything within, say, 10ms of the original timer also gets called back). The timing window is configurable. What platforms does the library work on? Been compiling this on my mac. Will have it running on Centos shortly. Haven't tried it at all on Win platform yet.
BR, Dmitry
Thanks, John Q.
JohnQ wrote:
Do you hold a mutex locked while invoking a callback?
yes, I'm holding a boost::unique_lock<boost::mutex>... as a result, the callback method shouldn't do much. Mine only records the fact that the timer fired and the data passed back and puts it on a queue for another of my app threads to handle.
Boost.Asio also holds a mutex.
What mechanism do you use to suspend till it's time to fire a callback?
boost::condition_variable m_timed_cond.timed_wait(timer_lock, cur_timer)
This approach has a drawback. After the timeout expires timed_wait() has to lock a mutex. And this can take arbitrary long. Especially if there are other threads that are waiting for the same mutex. Any thread that came before your thread will, most probably, acquire the mutex before your thread. This obviously spoils precision. Why dont you use a semaphore instead? In order to improve precision, the library can also wait a bit less than the client asked to give the thread some time to resume. Under high load the scheduler can give your thread the processor long later than you asked.
What is the precision of your library? I mean if you instruct the library to invoke your callback in so many ms usually your callback will be invoked at bit later. The question is how long later? Or earlier?
Typically fires later than earlier... the tolerance window I've been using is 5 ms - 10ms. The unit test included in the lib I uploaded to boost value includes a test that puts 100 timers up and measures when they fire. Occassionally out of that window. So far I've been running this on my mac and there's a lot running on it typically, so I'm suspicious of my results and think they could be better.
Does the precision degrade when you register lots of callbacks?
Not that I know of... I've put a couple of hundred thousand in there... so far the time to rebalance the underlying map for insertion / deletion hasn't shown up as an effect.
What's the smallest possible timeout the library lets to register a callback with? How does the library handle small (e.g. 1 ms) timeout requests?
Currently, millisecond resolution but totally happy to change it to reflect the greatest accuracy the underlying system timer can achieve. I've been testing this with a timing window (i.e., anything within, say, 10ms of the original timer also gets called back). The timing window is configurable.
What platforms does the library work on?
Been compiling this on my mac. Will have it running on Centos shortly. Haven't tried it at all on Win platform yet.
Thanks, John Q.
BR, Dmitry
participants (2)
-
Dmitry Goncharov -
JohnQ