About atomicity guarantee in C

Question

On x86 machines, instructions like inc, addl are not atomic and under SMP environment it is not safe to use them without lock prefix. But under UP environment it is safe since inc, addl and other simple instructions won't be interrupted.

My problem is that, given a C-level statement like

x = x + 1;

Is there any guarantees that C compiler will always use UP-safe instructions like

incl %eax

but not those thread-unsafe instructions(like implementing the C statement in several instructions which may be interrupted by a context switch) even in a UP environment?

Answer 1

I believe you need to resort to SMP targeted libraries or else roll your own inline assembler code.

Answer 2

No.

You can use "volatile", which prevents the compiler from holding x in a temporary register, and for most targets this will actually have the intended effect. But it isn't guaranteed.

To be on the safe side you should either use some inline asm, or if you need to stay portable, encapsulate the increment with mutexes.

Answer 3

A C compiler may implement a statement like x = x + 1 in several instructions.
You can use the register keyword to hint the compiler to use a register instead of memory, but the compiler is free to ignore it.

I suggest to use OS lock specific routines like the InterlockedIncrement Function on Windows.

Answer 4

Is there any guarantees that C compiler will always use UP-safe instructions

Not in the C standard. But your compiler/standard library may provide you with special types or certain guarantees.

This gcc doc may be along the lines of what you need.

Answer 5

If you use GLib, they have macros for int and pointer atomic operations.

http://library.gnome.org/devel/glib/stable/glib-Atomic-Operations.html

Answer 6

Worrying about just x86 is horribly unportable coding anyway. This is one of those seemingly small coding tasks that turns out to be a project in itself. Find an existing library project that solves this sort of problem for a wide range of platforms, and use it. GLib seems to be one, from what kaizer.se says.

Answer 7

There is absolutely no guarantee that "x - x + 1" will compile to interrupt-safe instructions on any platform, including x86. It may well be that it is safe for a specific compiler and specific processor architecture but it's not mandated in the standards at all and the standard is the only guarantee you get.

You can't consider anything to be safe based on what you think it will compile down to. Even if a specific compiler/architecture states that it is, relying on it is very bad since it reduces portability. Other compilers, architectures or even later versions on the same compiler and architecture can break your code quite easily.

It's quite feasible that x = x + 1 could compile to an arbitrary sequence such as:

load r0,[x]  ; load memory into reg 0
incr r0      ; increment reg 0
stor [x],r0  ; store reg 0 back to memory

on a CPU that has no memory-increment instructions. Or it may be smart and compile it into:

lock         ; disable task switching (interrupts)
load r0,[x]  ; load memory into reg 0
incr r0      ; increment reg 0
stor [x],r0  ; store reg 0 back to memory
unlock       ; enable task switching (interrupts)

where lock disables and unlock enables interrupts. But, even then, this may not be thread-safe in an architecture that has more than one of these CPUs sharing memory (the lock may only disable interrupts for one CPU), as you've already stated.

The language itself (or libraries for it, if it's not built into the language) will provide thread-safe constructs and you should use those rather than depend on your understanding (or possibly misunderstanding) of what machine code will be generated.

Things like Java synchronized and pthread_mutex_lock() (available to C under some OS') are what you want to look into.

Answer 8

In recent versions of GCC there are __sync_xxx intrinsics to do exactly what you want.

Instead of writing:

x += 1;

write this:

__sync_fetch_and_add(&x, 1);

And gcc will make sure this will be compiled into an atomic opcode. This is supported on most important archs now.

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html

It stems originally from the recommendations from Intel for C on ia64, but now found it ways to gcc on a lot of other archs, too. So it's even a bit portable.