Re: [boost] boost.timer library submission...

Subject: Re: [boost] boost.timer library submission...
From: Dmitry Goncharov (dgoncharov_at_[hidden])
Date: 2009-06-05 04:21:38

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
>
>