Why the ‘volatile’ Keyword Saves Your Embedded C Code (And Common Misconceptions)

Introduction: The volatile keyword

In C programming, the volatile keyword tells the compiler that a variable may be changed by factors outside the program’s control, so every read or write must be performed exactly as written without optimization.

What is volatile? A story

A programmer writes code to turn an LED on and off by writing to a memory‑mapped register. Without volatile, the compiler optimizes away the first write and the empty loop, leaving only the final assignment, so the LED never lights.

int main(){
    int *LED_STATUS = (int*)0x40000000;
    *LED_STATUS = 1; // set LED on
    for(int i=0;i<1000000;i++){}
    *LED_STATUS = 0; // set LED off
    return 0;
}

After optimization the generated code becomes:

int main(){
    int *LED_STATUS = (int*)0x40000000;
    *LED_STATUS = 0; // only the last assignment remains
    return 0;
}

Consequently the LED never turns on.

volatile saves the day

int main(){
    volatile int *LED_STATUS = (int*)0x40000000;
    *LED_STATUS = 1; // this write is kept
    for(int i=0;i<1000000;i++){}
    *LED_STATUS = 0; // also kept
    return 0;
}

Adding volatile prevents the compiler from discarding the writes and the delay loop, allowing the hardware to see the intended changes.

True meaning of volatile

The keyword essentially gives two guarantees:

Prevent optimization : the compiler must not remove or reorder accesses to a volatile object.

Prevent reordering : accesses occur in the order written in the source.

Note that in C, volatile does **not** guarantee memory visibility across multiple CPU cores or threads; it only affects the compiler’s code generation.

When to use volatile?

1. Hardware registers (most common)

Registers can change independently of the program, so they must be declared volatile to ensure each access reads the actual hardware state.

volatile unsigned int *timer_register = (unsigned int *)0x40001000;

2. Shared variables in multithreading (caution)

Some developers mistakenly think volatile makes a variable instantly visible to other threads. It does not; proper synchronization primitives (mutexes, atomics, memory barriers) are required.

volatile int shared_flag = 0;

void thread1(){
    shared_flag = 1; // write
}

void thread2(){
    while(!shared_flag){}
}

On modern multicore CPUs, the loop may never observe the change because caches are not synchronized.

3. Variables accessed in signal handlers

volatile int signal_occurred = 0;

void signal_handler(int sig){
    signal_occurred = 1;
}

int main(){
    signal(SIGINT, signal_handler);
    while(!signal_occurred){}
    return 0;
}

Here volatile ensures the main loop reads the flag updated by the asynchronous handler.

Common misconceptions

volatile guarantees memory visibility – false; it only stops compiler optimizations.

volatile guarantees atomicity – false; individual reads/writes may still be torn.

volatile can replace locks – false; locks provide atomicity and memory ordering that volatile does not.

All global variables should be volatile – false; only variables that can change outside the program’s flow need it.

C and Java volatile are the same – false; Java’s volatile also enforces memory visibility, which C’s does not.

A vivid analogy

Think of volatile as a “hot‑water” warning label on a kettle. It tells anyone (the compiler) not to touch the kettle carelessly (optimize away accesses) and to always check the actual temperature (read from memory) before using it. However, if two people are in different rooms (different CPU cores), one may miss the label entirely, illustrating why volatile does not guarantee cross‑core visibility.

Summary: Five take‑aways

volatile tells the compiler “this variable may change at any time; don’t optimize my accesses.”

In C, volatile does not ensure memory visibility across threads or cores.

Typical uses are hardware registers, signal‑handler flags, and very limited multithreaded cases.

volatile provides neither atomicity nor a substitute for locks or memory barriers.

Overusing volatile harms performance; apply it only where truly needed.