Volatile, visibility and lost events
A CAN interrupt updates a flag, but a task misses work. Separate observable accesses from synchronization and event capacity.
The guarantee
Accesses to volatile-qualified objects are observable according to the implementation's rules. The compiler must preserve required volatile accesses. That does not promise an atomic read-modify-write, mutual exclusion, inter-core ordering or cache coherence.
Hardware and interrupts
Peripheral registers often need volatile access through vendor-provided definitions. Interrupt-shared objects require the compiler and MCU's documented rules plus appropriate synchronization. Volatile alone is not a valid general solution for C or C++ thread data races.
A Boolean cannot count
If two interrupts both set pending to 1 before the task runs, the task sees one pending indication. A second event can also be lost between reading and clearing. Use an appropriately synchronized counter, queue or OS event mechanism according to whether counts, payloads or only a wake-up must be preserved.
/* Illustrates event collapse, not a complete synchronization design. */
static volatile unsigned pending;
/* ISR A: pending = 1; */
/* ISR B: pending = 1; */
/* Task observes one pending indication. */Follow each transition
ISR writes 1
First event changes pending from 0 to 1.
Conceptual sequence. Timing is slowed for learning; it is not a hardware measurement.
Your investigation
Choose a design for receiving bursts of CAN frames without silently discarding payloads.
Reveal the investigation checklist
- Define the maximum burst and consumer latency.
- Choose a bounded queue and an explicit overflow policy.
- Use an ISR-safe synchronization mechanism.
- Test burst traffic with the optimized build.
What does volatile alone provide?
Answer the knowledge check correctly to complete this lesson.
Think through Volatile, visibility and lost events
Ask for an explanation, an automotive example or a question that tests your understanding.
Checking mentor availability…