Is it safe to share a volatile variable between the main program and an ISR in C?

Question

Is it safe to share an aligned integer variable, not bigger than the processor natural word, with volatile qualifier, between the main program and an ISR in C? Is it guaranteed that no torn reads or writes may happen?

Answer 1

The volatile keyword does not imply atomicity - that simply ensures that a variable is explicitly read and not assumed not to have changed. For safe shared access without any other protection mechanism the variable must be both atomic and declared volatile.

The compiler may document types that are atomic for any particular target, and may define sig_atomic_t for this purpose.

In general it is perhaps reasonable to assume that your compiler will not do anything perverse and split an aligned word read where the instruction set allows an atomic read. Caution should be applied however when porting code between platforms - such low level code should be regarded as target specific and non-portable.

Answer 2

Regarding the volatile keyword, it is just there to protect against possible incorrect optimizations by the compiler. It doesn't help with thread safety.

Whether or not it is thread-safe to use a shared variable of a given size is up to the compiler. There are no guarantees that access is atomic. For example the compiler might load the variable into a register before further processing, then write it back to memory afterwards. Mostly depends on CPU instruction set. If you want to be sure, you will have to check the disassembled code or write the code in assembler.

Otherwise, you can make a "poor man's mutex" with a bool. This only works for the specific case of microcontroller ISRs that cannot be interrupted by other interrupts. Since you know the ISR can't be interrupted, you can do this:

static volatile bool busy;
static volatile uint16_t shared;

void isr (void)
{
  if(!busy)
  {
    shared = something;
  }
}


void main (void)
{
  ...

  busy = true;
  do_something(shared);
  busy = false;

  ...
}

With this approach, it doesn't matter if busy or shared are atomic or not. No matter where the interrupt triggers, shared will not get destroyed mid-access.

Answer 3

Check your compiler. ISR's are non-standard. Also, C has no real notion of "the processor natural word" other than perhaps int.

Answer 4

The answer is "sometimes". If the either ISR or the main process alters the variable, then you are OK. However if both manipulate the variable, something like

main
Var = Var + 10

ISR
Var = Var + 10

Then who knows? You would think the final result would be var + 20, but if in assembly the the sequence is

Main - Get Var
ISR -            Get Var
                 Add 10
                 Store Var
                 Return
       Add 10
       Store Var

Then the final result will be 10, not 20

As the previous poster said you will need to have some protection code to prevent this.

Answer 5

There is no guarantee that any generic integer variable will be written and read atomically. If you need such a guarantee you should use the sig_atomic_t type. It is the only type with such a guarantee.

From the C99 standard 7.14:

2 The type defined is

sig_atomic_t

which is the (possibly volatile-qualified) integer type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts.