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:
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
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?
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"
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).