Safest way to implement multiple timers inside a thread in C++ - c++

Question

As the title says, I'm looking for the best way to implement multiple timers in C++ (not c++ 11).
My idea is having a single pthread (posix) to handle timers.
I need at least 4 timers, 3 periodic and 1 single shot.
The minimum resolution should be 1 second (for the shortest timer) and 15 hours for the longest one.
All the timers should be running at the same time.
These are the different implementations that come to my mind (I don't know if they are the safest in a thread environment or the easiest ones):
1) Using itimerspec, sigaction and sigevent structure like this:
static int Tcreate( char *name, timer_t *timerID, int expireMS, int intervalMS )
{
struct sigevent te;
struct itimerspec its;
struct sigaction sa;
int sigNo = SIGRTMIN;
sa.sa_flags = SA_SIGINFO;
sa.sa_sigaction = app;
sigemptyset(&sa.sa_mask);
if (sigaction(sigNo, &sa, NULL) == -1)
{
perror("sigaction");
}
/* Set and enable alarm */
te.sigev_notify = SIGEV_SIGNAL;
te.sigev_signo = sigNo;
te.sigev_value.sival_ptr = timerID;
timer_create(CLOCK_REALTIME, &te, timerID);
its.it_interval.tv_sec = 0;
its.it_interval.tv_nsec = intervalMS * 1000000;
its.it_value.tv_sec = 0;
its.it_value.tv_nsec = expireMS * 1000000;
timer_settime(*timerID, 0, &its, NULL);
return 1;
}
2) Using clock() and checking for time difference, like this:
std::clock_t start;
double duration;
start = std::clock();
duration = ( std::clock() - start ) / (double) CLOCKS_PER_SEC;
3) Using chrono like this:
auto diff = tp - chrono::system_clock::time_point();
cout << "diff:" << chrono::duration_cast<chrono::minutes>(diff).count()
<< " minute(s)" << endl;
Days days = chrono::duration_cast<Days>(diff);
cout << "diff:" << days.count() << " day(s)" << endl;
Please, consider these as ideas, not actual working code.
What is your opinion about it ?

Answer 1

If your timer thread is responsible only for the timers, and the minimum resolution is 1 second, and the timing doesn't need to be that precise (i.e. if +/- 0.1 second is good enough), then a simple implementation for the timer thread is to just sleep for 1 second, check for any timers that need to fire, and repeat, as in the following psuedocode:
repeat:
sleep 1
t = t+1
for timer in timers where timer(t) = true:
fire(timer)
The hard part will be populating the structure that stores the timers - presumably timers will be set by other threads, possibly by multiple threads that could try to set timers simultaneously. It would be advisable to use some standard data structure like a thread-safe queue to pass messages to the timer thread, which on each cycle would then update the collection of timers itself:
repeat:
sleep 1
t = t+1
while new_timer_spec = pop(timer_queue):
add_timer(new_timer_spec)
for timer in timers where timer(t) = true:
fire(timer)
Another thing to consider is the nature of fire(timer) - what to do here really depends on the needs of the threads that use the timers. Perhaps just setting a variable that they could read would be sufficient, or maybe this could fire a signal that threads could listen for.

Answer 2

Since all your timer creation apparently goes through a single API (i.e., the controlling code has visibility into all timers), you can avoid signals or busy-looping entirely and keep a sorted list of timers (like a std::map keyed by deadline), and simply wait on a condition variable using (for example) pthread_cond_timedwait. The condition variable mutex protects the list of timers.
If you schedule a new timer whose deadline is earlier than the current "next" timer, you'll need to wake the sleeping thread and schedule an adjusted sleep (if it wasn't for this requirement you could use plain usleep or whatever). This all happens inside the mutex associated with the condition variable.
You don't have to use condition variables, but they seem the cleanest, since the associated mutex is naturally used to protect the list of timers. You could probably also build this on top of a semaphone with sem_timedwait, but or on top of select on an internal socket, pipe or something like that, but then you're stuck separately controlling multi-threaded access to the timer queue.