8 Timer Implementation Patterns for Systems and Network Software

When it comes to managing timers in systems and network software, engineers have discovered several reliable patterns. At the hardware level, timer peripherals generate interrupts that trigger timer handlers. However, this approach limits the number of timers due to hardware constraints. Operating system timers, accessible via functions like setitimer() or timer_create(), provide a convenient way to handle timers using the OS scheduler.

Timer wheels offer a scalable solution by organizing timers into slots based on their expiry times, enabling O(1) insertion and deletion. This is particularly useful for networking software dealing with thousands of timers. Priority queues, represented by min-heaps, store timers in order of expiry, allowing for quick access to the next timer to fire.

While this method maintains good precision, it incurs O(log n) insertion and deletion costs. A sorted linked list of timers is easy to implement but becomes inefficient as the number of timers grows. In event-driven systems, software timers can be managed by a dedicated thread or task that checks the list of active timers at fixed intervals.

This polling-based approach simplifies the design but sacrifices some precision for predictable CPU usage. Modern user-space daemons often employ event-driven frameworks, such as epoll or libevent, where timers are treated as one type of event within an integrated event loop alongside I/O events. Lastly, the delta queue, an optimized version of a sorted list, stores the time difference between timers, reducing unnecessary updates during each tick.

When selecting a timer implementation, timer wheels and event-loop-integrated timers are preferred for high-performance networking daemons due to their scalability and integration with I/O-driven architectures. Other patterns have specific use cases, but for scale, starting with a timer wheel or event loop is a recommended approach.