Re: [boost] first review submission of timer_queue.zip

Subject: Re: [boost] first review submission of timer_queue.zip
From: JohnQ (jqs_at_[hidden])
Date: 2009-06-13 23:36:07

>> Thanks to any who take the time to review this and help me make it
better.
>
>Why the call_back is associated to the timer_queue and not to the timeout?
If I understand your question correctly, it's because this allows me to look
at a "window" of time when the current timer expires. That way I can call
the callback multiple times for timers that are all within the current
"window" to avoid invoking context switches for each of those timers.

>
>Do we really need several timer queues? Shouldn't only one be enough? IMO
the class timer_queue  >muts be hiden to the user. The interface I would
like to use is something like,
>
>   auto h = after_call(miliseconds(10), f, x, y);
>or
>   auto h = at_call(now()+miliseconds(10), f, x, y);
>
>   if (some condition) {
>       h.interrupt();
>   }

Let me take a closer look at this and make another reply... I'm short on
time right now... but I have a question about the first part...  there
should only be one timer queue... and actually the container behind the
scenes is a multi-index map (not really a queue).

>
>The user should be also able to wait until the timeout has expired and the
function called. So
>
>   h.wait()
>
>will synchronize with the end of the function call f(x,y). If in addition f
returns something the
>following should also be correct
>
>   auto res = h.get()
>
>So the handle returned by
>   auto h = after_call(miliseconds(10), f, x, y);
>
>must implement the future interface (an asynchronous completion token).

I think I agree... but need more time to go through your suggestion.

>
>There are classic implementation using a well instead of a queue which make
insertion independent
>of the number of active timers (see for example "Redesigning
>the BSD Callout and Timer Facilities" by Adam M. Costello, George Varghese
>
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=B5202FC949FF3EDB0E789F68F509950C?doi=10.1.1.54.6466&rep=rep1&type=pdf
).
>

Yes, this is good advice... I'll take a look.

>Best regards,
>Vicente

Excellent !  Thanks for giving this a detailed look Vicente.

----- From Dmitry----
>>>> 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.

Thanks Dmity!  As with my answers to Vicente above, let me take a closer
look and reply. I've been completely swamped, the last 1-2 weeks and I'm
just coming out of it. :)

Thanks,
John Q.