CODEWITHSUNDEEP
c++multithreadingc++11concurrencymemory-barriers
choxsword
choxsword

Reputation: 3369

Why isn't fetch_sub a release operation?

Quoted from C++ Concurrency in Action $Listing 5.9

A fetch_sub operation with memory_order_acquire semantics doesn’t synchronize-with anything, even though it stores a value, because it isn’t a release operation. Likewise, a store can’t synchronize-with a fetch_or with memory_order_release semantics, because the read part of the fetch_or isn’t an acquire operation.

It's hard to understand the paragraph above for me. If a fetch_sub operation with memory_order_acquire semantics doesn’t synchronize-with anything, why does the interface of fetch_sub leave a memory order parameter for us as following?

T fetch_sub( T arg, std::memory_order order = std::memory_order_seq_cst ) noexcept;

Upvotes: 4

Views: 341

Answers (1)

T.C.
T.C.

Reputation: 137425

  1. "synchronize with" is unidirectional and not commutative. "A synchronizes with B" doesn't imply "B synchronizes with A" (in fact, quite the opposite), unlike what one might expect from English. Thus, a memory_order_acquire RMW operation can't synchronize with anything, but a memory_order_release store synchronizes with a memory_order_acquire RMW operation that takes the value read from the store. Similarly, while a memory_order_release store doesn't synchronize with a memory_order_release RMW, a memory_order_release RMW can synchronize with a memory_order_acquire load.
  2. memory_order_acq_rel.

Upvotes: 3

Related Questions