2

As far as I know, atomic operations of atomic type in cpp11 are guaranteed to be aomtic. However, suppose in multi-core system, if two threads do following operation simultaneously, will the result be 1?(suppose initially atomic<int> val=0;) It seems that the result is guaranteed to be 2, but why?

val.fetch_add(1,std::memory_order_relaxed);

As a supplement, suppose another situation, if thread1 do val.load(2); thread2 do val.load(3), it seems that the result is whether 2 or 3,but not certain which one either.

choxsword
  • 3,187
  • 18
  • 44

1 Answers1

5

Even if 1000 threads execute fetch_add at the "same time", the result will still be 1000. This is the whole point of atomic operations: they are synchronized.

If we had to worry about any atomic operations not being synchronized/visible to other threads, then we wouldn't have atomic operations to begin with.

When executing an atomic operation (like fetch_add) you are guaranteed that only one atomic operation starts and finishes at any given time, and it cannot be overlapped/interrupted by other atomic operations started in other threads.

Josh Correia
  • 3,807
  • 3
  • 33
  • 50
David Haim
  • 25,446
  • 3
  • 44
  • 78
  • I know that atomic operation does not have intermediate state.They are either done or not done. But I'm confused about what will happen if two atomic operation happen simultaneously. Do you mean that atomic operaion will not happen simultaneously? – choxsword Jul 29 '18 at 13:02
  • They can not happen simultaneously. one thread will wait until the `fetch_add` finishes in another thread. atomicity = synchronization + visibility + memory order enforcement. – David Haim Jul 29 '18 at 13:04
  • Thanks, so there must be a happening sequence between atomic operations **even in multi-cpu system** , but not specifying which one first? – choxsword Jul 29 '18 at 13:05
  • Sorry, I don't understand your question. – David Haim Jul 29 '18 at 13:06
  • You said that "atomicity = synchronization + visibility + memory order enforcement." But as far as I know, the **relaxed order** does not guarantee sychronized with relationship – choxsword Jul 29 '18 at 13:09
  • It is. *If it's atomic - it's synchronized and visible*. memory order relaxed basically says that the compiler/CPU may schedule another atomic operation before or after this operation, even though the code says otherwise. but the visibility and synchronization are still there. – David Haim Jul 29 '18 at 13:10
  • But the visibiliby are not guaranteed under **relaxed memory model**, it's guaranteed in **acquire release** model. – choxsword Jul 29 '18 at 13:14
  • Where did you get it from? every atomic operation, even relaxed ones, guarantees visibility and synchronization. memory ordering just guarantees the **order** of atomic operations and nothing more. – David Haim Jul 29 '18 at 13:15
  • and If a relaxed operation doesn't guarantee any synchronization/visibility, what's its point over regular, non atomic, reading/writing? – David Haim Jul 29 '18 at 13:17
  • [I' ve raised a new question about concurrency](https://stackoverflow.com/questions/51580966/confusion-about-happens-before-relationship-in-concurrency) – choxsword Jul 29 '18 at 13:50
  • [Here is an example in book **Concurrency in Action**](https://paste.ubuntu.com/p/Vmw2B2BZK9/). It seems like the modify using relaxed order in one thread is not immediately visible to other thread. – choxsword Jul 30 '18 at 02:33
  • [And I've raised a new question about visibility](https://stackoverflow.com/questions/51586366/could-the-side-effect-of-atomic-operation-be-seen-immediately-by-other-threads) – choxsword Jul 30 '18 at 03:15