...

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.