Question

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

I believe that the following code increases the value of var atomically.

volatile int var = 0;
__sync_fetch_and_add( &var, 1 )

I understood the above codes as the following logic:

1. Load the address of variable var
2. write number 1 onto variable var atomically – through register/cache, somehow

However, I doubt if the following is atomic, too

volatile int var = 0;
volatile int num = 1;
__sync_fetch_and_add( &var, num )

Since it may be interpreted as

1. Load the address of variable var
2. Load the value of variable num into a register
3. write the value onto variable var.

After #2 is executed, but before #3,
the CPU/thread gets interrupted and another CPU/thread updates
the value of variable num.

In other words,
when using _sync*() of gcc,
can I use a variable, not a constant, as the second argument?

Doesn’t it break the atomicity?

Answer 1

The operation is really two operations.

__sync_fetch_and_add( &var, num )

Loading num is atomic. Adding it to var is atomic. But two atomic operations do not make an atomic operation when put together. This is why it is so hard to invent new lock-free data structures. In general, two thread-safe operations do not necessarily make a thread-safe operation when composed. This is the reason why it is so difficult to make correct multithreaded applications.

You see, __sync_fetch_and_add is indeed atomic, but it behaves like an ordinary function — so it takes the current value of “num” as a parameter. It is not quite correct to say the atomicity of the function is broken — because it is the responsibility of the caller to load the value from num, and it’s not part of the function’s interface. I could equally complain about this:

__sync_fetch_and_add(&var, some_really_long_function());

Or worse,

__sync_fetch_and_add(long_function_1(), long_function_2());

You say it “may be interpreted as”

1. Load the address of variable var
2. Load the value of variable num
3. Perform the atomic addition

But according to the C spec, it’s not that it may be interpreted this way, but rather, it must be interpreted this way, otherwise the compiler would not be conformant (actually, it could swap #1 and #2, but that’s not important here).