mediumConceptCodingEntryMidSenior
What belongs inside an interrupt service routine, and what must be kept out of it?
Interrupt service routine rules are simple: acknowledge the hardware, capture the minimum safe state and return fast. Blocking calls, allocation, logging and long loops belong in deferred work because ISR runtime becomes worst-case latency for interrupts at the same or lower priority.
5 min readUpdated 2026-08-15
Answer
Short answer
Keep an ISR tiny: acknowledge the device, copy the minimum data, schedule deferred work, and avoid blocking, allocation, logging or loops that stretch interrupt latency.
Keep interrupts explicit in the answer because that is the concept the interviewer is actually trying to test.
Was this answer helpful?
Likely follow-ups
- Your handler updates a 64-bit microsecond counter that the main loop reads. How do you make that read safe without disabling interrupts?
- Why can clearing a peripheral's interrupt flag on the last line of the handler cause the handler to run twice?
- How do you measure the real worst-case execution time of a handler on hardware rather than reasoning about it?
- When is it correct to do the whole job inside the ISR and defer nothing?
Related questions
- A flash sale decrements stock from many threads. Do you go optimistic or pessimistic, and how do you prove nothing oversold?mediumAlso on concurrency5 min
- How would you design a thread-safe component, and why is adding synchronized to every method not a design?hardAlso on concurrency7 min
- Two threads write to adjacent counters and throughput collapses. What is happening and how do you fix it?hardAlso on concurrency5 min
- Every call you make is on a ConcurrentHashMap, and you still lost an update. How does a thread-safe collection get raced?hardAlso on concurrency5 min