In bare-metal firmware, ordinary code and interrupt handlers can access the same state even on a single-core processor. The interrupt can occur between two ordinary instructions, creating a concurrent foreground-background execution model.

An interrupt service routine should usually do the minimum work needed to make the event safe and record what happened. Lengthy computation or blocking inside a handler increases interrupt latency for other events.

Shared state requires an explicit synchronization strategy. A short critical section can temporarily mask the relevant interrupt; alternatively, the handler can place data or an event into a buffer that ordinary code consumes later.

The programming language must also preserve the accesses that can be affected asynchronously. In C, volatile can be relevant to that compiler-level requirement, but it does not make a multi-step update atomic and does not by itself prevent races.

Nested interrupts introduce additional interleavings when a higher-priority handler can preempt a lower-priority one.

Interrupt-driven firmware therefore has concurrency even without threads: correctness must hold for every permitted point at which asynchronous handlers can run.