Interrupts on multicore systems

Updated: April 19, 2023

On a multicore system, each interrupt is directed to one (and only one) CPU, although it doesn't matter which. How this happens is under control of the programmable interrupt controller (PIC) chip(s) on the board. When you initialize the PICs in your system's startup, you can program them to deliver the interrupts to whichever CPU you want to; on some PICs you can even get the interrupt to rotate between the CPUs each time it goes off.

For the startups we write, we typically program things so that all interrupts (aside from the one(s) used for interprocessor interrupts) are sent to CPU 0. On systems running 7.x and later, we support per processor interrupt controllers (LAPIC interrupts on x86-based systems and GIC PPIs on ARM-based systems). For these interrupts, you can encode which CPU's interrupt you're interested in the InterruptAttach() or InterruptAttachEvent() vector number – as a result, that's the CPU the interrupt occurs on.

For more information, see the Startup Programs chapter of Building Embedded Systems.

An ISR (Interrupt Service Routine) that's added by InterruptAttach() runs on the CPU that takes the interrupt.

An IST (Interrupt Service Thread) that receives the event set up by InterruptAttachEvent() runs on any CPU, limited only by the scheduler and the runmask.

A thread that calls InterruptWait() runs on any CPU, limited only by the scheduler and the runmask.

As mentioned previously, typically in the startups we provide, we direct interrupts to CPU 0, but if your system design requires that you route the interrupts to another CPU, you can see the examples in the following "Example of modifying the interrupt controller in a BSP when using InterruptAttach()" and Example of using InterruptAttachEvent() to handle sigevents on a specific CPU sections.