Hardware timer per thread?

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
robfinch
Posts: 3
Joined: Sun Jun 22, 2025 12:28 am

Hardware timer per thread?

Post by robfinch »

Contemplating the use of hardware timers. How many timers is enough? I think this can be done in hardware. If they had a pre-scaler they do not all have to operate in parallel. For instance, if pre-scaled by 32, 32 parallel hardware timers could be turned into 1024 timers using dedicated RAM to keep track of the counts and sequencing through the timers using the 32 pre-scaler counts. A larger pre-scale and more RAM would allow more timers. Would a timer per thread be enough?
Pre-scaling could affect the timer resolution, but would still allow high-resolution.
rdos
Member
Member
Posts: 3383
Joined: Wed Oct 01, 2008 1:55 pm

Re: Hardware timer per thread?

Post by rdos »

robfinch wrote: Thu Jul 10, 2025 2:36 am Contemplating the use of hardware timers. How many timers is enough? I think this can be done in hardware. If they had a pre-scaler they do not all have to operate in parallel. For instance, if pre-scaled by 32, 32 parallel hardware timers could be turned into 1024 timers using dedicated RAM to keep track of the counts and sequencing through the timers using the 32 pre-scaler counts. A larger pre-scale and more RAM would allow more timers. Would a timer per thread be enough?
Pre-scaling could affect the timer resolution, but would still allow high-resolution.
I think you are too much influenced by the BIOS timer which is implemented with the PIT. This kind of timers are not good for anything. You get one tick every 1/18.2 seconds, but the PIT has microsecond resolution. For timers, you either need one per system or one per processor core, the latter being optimal. Then you keep a list of active timers per system or per core. The API would have a timeout time (in whatever resolution you desire, like PIT tics, nanoseconds) and a callback. The OS then starts the timer (if the request is at the head) by programming the hardware timer. When the timer IRQ happens, the callback is called (in the IRQ context). This provides microsecond resolution using the PIT. Then there is also another user case: You want to know elapsed time. This is best implemented by having a three-running counter/timer per system, like the HPET, but the PIT can be used too. You read the timer in the API and then add to an accumulated count. No IRQ is required, as the accumulated count can be updated in the scheduler to avoid timer/counter wrap. This too can be implemented with microsecond resolution (with PIT), or nanosecond with better timers.
Post Reply