Boost logo

Boost :

Subject: Re: [boost] first review submission of
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
>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);
> 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

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

>Best regards,

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

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. :)

John Q.

Boost list run by bdawes at, gregod at, cpdaniel at, john at