# Timer class

This topic is 3614 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

##### Share on other sites
Why can't you only sleep in periods of 100ms or so and check queue every time your thread wakes up?

##### Share on other sites
That actually had not occurred to me, and is a very simple solution. In the purely academic sense, it is a form of busy-waiting (albeit a very slow kind of busy), but I think practically speaking it would be fine.

Another option would be to switch from the feature-scarce GLFW thread functions to boost::thread. I would get thread::interrupt(), and also some shared locking stuff that could simplify other parts of the code.

The createTimer function would interrupt the timer thread if it's sleeping on an event that happens later than the new event. The handling loop would have to catch a boost::thread_interrupted exception and act accordingly.

##### Share on other sites
Or, you could wait on a condition variable, specifying a timeout equal to the closest scheduled event in the future (which may be 1 second, or 5 seconds, or whatever).
When another thread adds an event, it signals the condition variable, so you can recalculate the next closest event, possibly do something, and go to sleep again.

Actually a semaphore would do too for this application... but unluckily, GLFW doesn't have semaphores, so you'll need a GLFWCond.

##### Share on other sites
You might not want to mess with threads if you can help it. The solution becomes *much* easier with respect to many other issues, and also much more deterministic:
while (running) {  time t = now();  handleInput();  handleExpiredTimers(t);  updateLogic(t);  render();};
In handleExpiredTimers you check, duh, which timers expired and notify interested parties.

This makes timing somewhat more predictable as well, since times are no longer bound to system time but actual logic time.

Always remember that threads are non-deterministic. They may be given processing time, or they might not. They make wake when desired, or they might not. This becomes a problem as soon as the CPU is overloaded and threads start to compete for resources. Not to mention that threaded timer invocations require you to lock the state.

And never use Sleep() for anything that resembles a timer based on real time. Sleeping means to sleep at least that long, but it may sleep forever or for 3 hours. If you need a periodic event that needs to do something every once in a while, the Sleep is ok. But emphasis is on "once in a while".

##### Share on other sites
samoth, this is basically the solution that was winning out in my mind. I will probably switch to boost::thread at some point, but I just double checked and boost doesn't have a semaphore either. So it would still be a similar situation.

Antheus, point well taken. The EventHandler class above it is *pervasively* multithreaded, handing off tasks to a thread pool, so I have already perpetrated many crimes against determinism. However, that class also provides a no-thread/stepping solution, so I should probably do something similar for EventTimer.

This has been a learning and portfolio-building project, so some of the design is more rooted in curiosity that it is in practicality. \o/

Thanks for the replies.

1. 1
Rutin
33
2. 2
3. 3
4. 4
5. 5

• 13
• 76
• 11
• 10
• 14
• ### Forum Statistics

• Total Topics
632968
• Total Posts
3009584
• ### Who's Online (See full list)

There are no registered users currently online

×