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: 4
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.
robfinch
Posts: 4
Joined: Sun Jun 22, 2025 12:28 am

Re: Hardware timer per thread?

Post by robfinch »

I was thinking of timers with micro-second or better resolution. For instance, with a 100 MHz base clock the clock can be divided (scaled) by 100 and still have micro-second resolution.

The appeal of having a large number of timers is that there are no lists to manage. I think it would be possible that the OS does not need to manage the timers in the same manner.

It might be possible to have a callback directly into the app, with the app managing the timer. Sleep(timeout, callback). TimeThis(signal, callback). Although the OS would still need to be present.

I have been trying to move some of the OS functions into hardware. It may help to get rid of the timer lists.
nullplan
Member
Member
Posts: 1917
Joined: Wed Aug 30, 2017 8:24 am

Re: Hardware timer per thread?

Post by nullplan »

Have you guys ever heard of the LAPIC timer? It is a timer that runs on each thread separately, and runs as fast as the TSC. It has also been the standard way of interrupting a core in a time-based way for decades now.
Carpe diem!
Post Reply