28

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?

ddoman
  • 1,051
  • 1
  • 10
  • 12

1 Answers1

38

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).

Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
  • I wouldn't say loading num is atomic, because it overloads the meaning of the work atomic. Here we then use it to mean there no word-tearing for integer loads, but then also in the sense of an atomic operation, e.g. cache-line locking between read and write processer barriers. –  Sep 16 '12 at 12:51
  • @BlankXavier: But isn't that what atomic means in general? In other words, an atomic operation is one that occurs completely or not at all, which applies to all word-aligned loads and stores on many common architectures. It sounds like you are talking about ordering guarantees (provided by memory barriers), which are a different concept from atomicity -- two atomic operations may appear to occur in the opposite order from a different process, but that doesn't mean they're not atomic. – Dietrich Epp Sep 16 '12 at 13:31
  • Atomic in the sense of memory barrier/cache-line locking/LLSC is a very different and much larger set of concepts that atomic in the sense of reading a plain integer and not seeing word tearing. But most people don't know about the memory barrier/etc issues - I think it confusing to use the same word for both. –  Sep 16 '12 at 14:15
  • 1
    We don't use the same word for both: atomic operations are atomic, and memory barriers are memory barriers, they are different concepts with different names. However, memory barriers can be used to *create* certain atomic operations out of more primitive atomic operations, and you can use atomic operation in combination with memory barriers to create synchronization primitives. Most libraries of atomic operations include atomic operations with attached barriers because they are so useful together, but they are not the same thing. – Dietrich Epp Oct 02 '12 at 22:57
  • 5
    [As of GCC 4.8, __sync built-ins have been deprecated in favor of the __atomic built-in](https://stackoverflow.com/a/30878480/2550406) just leaving this here for anybody wanting to use __sync – lucidbrot Oct 21 '17 at 12:33
  • As far as I know, `num` is just a value, no magic involved, no atomicity there. – Pavel Šimerda Jan 06 '18 at 20:57