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?
GCC provides built-in versions of the ISO C99 floating-point comparison macros that avoid raising exceptions for unordered operands. They have the same names as the standard macros ( isgreater , isgreaterequal , isless , islessequal , islessgreater , and isunordered ) , with __builtin_ prefixed.
Atomic operations are intended to allow access to shared data without extra protection (mutex, rwlock, …). This may improve: ● single thread performance ● scalability ● overall system performance.
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With