Namespaces
Variants
Views
Actions

Talk:cpp/atomic/memory order

From cppreference.com

Contents

[edit] See also

Should we add books on particular topics as external links/see also? "C++ Concurrency in Action" explains this part well, --Cubbi 19:17, 21 September 2011 (PDT)

Sure, let's have an 'External links' section at the end of the page in question.P12 20:29, 21 September 2011 (PDT)

[edit] std::memory_order_release and memory_order_acquire example

In this example, both writes have release order and both reads have acquire order. Wouldn't it be sufficient that the second write has release order and the second read has acquire order? 188.97.0.41 04:50, 21 November 2011 (PST)

No: release on the store to y but not on the store to x would only guarantee that store to x happens-before store to y from the point of view of thread 1 and any thread that loads from y with at least memory_order_acquire (not consume or relaxed). You're suggesting that load from y is relaxed, that means no synchronization whatsoever, assert may fail --Cubbi 07:14, 21 November 2011 (PST)
I think this example is doing more synchronization than is required. It would work equally well if the x.store in thread1 used std::memory_order_relaxed and the x.load in thread2 used std::memory_order_relaxed. Also it would work equally well if x was just a regular int, not std::atomic<int>. It might be more instructive/realistic to make x a regular int in this example to show the power of an acquire/release pair.
I agree, it's important to show the ordering of non-atomics. Will update (or you do, if you have a good example) --Cubbi 15:51, 1 January 2012 (PST)
..updated. --Cubbi 13:26, 2 January 2012 (PST)

[edit] memory_order_acq_rel and non-RMW load/stores

It seems that memory_order_acq_rel is only valid on read-modify-write operations and not on loads or stores. This is documented in § 29.6.5.9 and § 29.6.5.13 of (of drafts N3242 or N3291). However, memory_order_seq_cst is valid on these operations. The documentation here at cppreference.com implies that memory_order_acq_rel should work on loads/stores, and further defines memory_order_seq_cst as effectively being a stronger form of memory_order_acq_rel. This should be updated to explain that memory_order_acq_rel is not valid on load()/store() but that memory_order_seq_cst is. --Kballard (talk) 23:34, 8 April 2014 (PDT)

[edit] Are memory_order_acquire and memory_order_release correct?

AFAIK an acquire happens before all succeeding loads and stores, and a release happens before all preceding loads and stores, while this page only talks about stores and ignores loads.

With the definitions in this page, it is not possible to implement a spinlock with acquire/release atomic operations.

84.94.198.183 05:29, 18 May 2014 (PDT) (Avi Kivity)