Interrupts – the Heartbeat of a Unix Kernel
Posted4 months agoActive4 months ago
leftasexercise.comTechstory
calmpositive
Debate
20/100
Operating SystemsInterruptsKernel Development
Key topics
Operating Systems
Interrupts
Kernel Development
The article explores the role of interrupts in Unix kernels, sparking a discussion on the complexities of handling interrupts and sharing state between cores in modern kernel development.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
9h
Peak period
1
9-10h
Avg / period
1
Key moments
- 01Story posted
Sep 4, 2025 at 6:09 PM EDT
4 months ago
Step 01 - 02First comment
Sep 5, 2025 at 3:36 AM EDT
9h after posting
Step 02 - 03Peak activity
1 comments in 9-10h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 5, 2025 at 6:30 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45132799Type: storyLast synced: 11/20/2025, 8:52:00 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
https://users.rust-lang.org/t/sharing-state-between-cores-an...
Normally, an interrupt handler should do only a very simple thing: it should insert an action item in an agenda queue (i.e. "to do" queue) that is monitored by a kernel thread and it should acknowledge the interrupt handling to the peripheral that has signaled it.
On older CPUs the interrupt handler might also need to do something to ensure that the corresponding kernel thread wakes up, but on better CPUs just writing the queue should automatically wake up a thread that monitors it.
The content of the queue and the write index in it are modified only by the interrupt handler, so no locks are needed for the queue. The kernel thread only reads the content of the queue and it only modifies its own read index.
If the interrupt handler finds that the queue is full (by comparing the indices), one of two policies can be applied, either the last interrupt is ignored or the previous interrupt is overwritten, therefore it will be ignored. Such events should not normally happen.
If the kernel thread modifies the read index during the handling of an interrupt, this is harmless. In the worst case, the interrupt handler may believe that the queue is full even if one position has just been freed. This leads to ignoring one interrupt. With a big enough queue, this should not happen. If the interrupt handler modifies the write index while the kernel thread examines the queue, this is harmless, because in the worst case the kernel thread will believe that the queue is empty when an item has just been added, so it will wait for the next item to be added in the queue. When the kernel thread finds a non-empty queue, it will execute all the requested actions, until the queue is empty.
In most interrupt handlers you do not need anything else than such a queue, which does not require locks.
In very rare cases one may have the need to modify the behavior of the interrupt handlers while they are running, which can be done using static configuration variables that are modified by the kernel using atomic instructions, e.g. atomic bit set or atomic bit clear instructions.