0

Acquire memory barriers on load and release memory barrier on stores are used for synchronization across threads.

Is there a use case for the opposite, i.e. an acquire memory barrier on a store and consequently a release memory barrier on a load?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
user3882729
  • 1,339
  • 8
  • 11
  • What do you mean by "barrier **on** stores"? `atomic_thread_fence` (a barrier/fence) is separate from a load or store *operation* like `foo.store(1, std::memory_order_release)`. If you mean using acquire as a memory *order* for a store operation like `.store(1, acquire)`, that's undefined behaviour: https://en.cppreference.com/w/cpp/atomic/atomic/store. GCC happens to compile it like `seq_cst`, clang happens to compile it like `relaxed`: https://godbolt.org/z/bfWYxcK4M – Peter Cordes Jul 30 '22 at 22:55
  • Even for "weird" cases [like a SeqLock](https://stackoverflow.com/questions/54611003/implementing-64-bit-atomic-counter-with-32-bit-atomics), you want an extra acquire barrier in the reader for load-load ordering, and an extra release barrier in the writer for store-store ordering. (https://preshing.com/20120913/acquire-and-release-semantics/) / – Peter Cordes Jul 30 '22 at 22:58
  • @PeterCordes here's a link that mentions about the use case for acquire memory barriers for store (and also the fact that it's UB). That said I'd like to understand that use case better or if there are other example uses. https://youtu.be/R0V4xJ9HZpA?t=3822 – user3882729 Jul 31 '22 at 04:37
  • Why didn't you quote the video in the question in the first place, and mention the Ticket Lock use-case it suggests? At least you can do that now to save future readers the trouble of figuring out how to explain to you something you already know. – Peter Cordes Jul 31 '22 at 05:24
  • (https://en.wikipedia.org/wiki/Ticket_lock doesn't make it obvious why you'd want an acquire store. It looks like the store at the end can be a plain store with release semantics with the version of the algorithm presented on wikipedia, since the thread that owns the lock knows what ticket number they had. No atomic RMW needed. But more importantly, no acquiring needed. So Fedor must be talking about a more complicated version of the algorithm.) – Peter Cordes Jul 31 '22 at 05:25
  • I may setup another question on implementation of ticket lock. I still don't see how a acquire store barrier is needed in that case. – user3882729 Jul 31 '22 at 05:25
  • 1
    Also, when you edit this question, note that the `std::memory_order` parameter is a *memory order*, not a "memory barrier". A compiler might end up implementing it with barriers, but in the C++ memory model, an operation is different from a 2-way fence. (https://preshing.com/20131125/acquire-and-release-fences-dont-work-the-way-youd-expect/) – Peter Cordes Jul 31 '22 at 05:27
  • I don't understand Fedor Pikus's comment in the video either. It's unclear to me how a ticket lock could use an "acquire store"; I agree that the Wikipedia algorithm certainly doesn't need one. – Nate Eldredge Jul 31 '22 at 14:56
  • 1
    Moreover, if Fedor wants to get the effect of an "acquire store" by doing an exchange (presumably acq_rel) and discarding the result, I think he's mistaken; as was discussed [here](https://stackoverflow.com/questions/65568185/for-purposes-of-ordering-is-atomic-read-modify-write-one-operation-or-two), an acq_rel RMW consists of an acquire load and a release store. It does not prevent operations sequenced after the RMW from being reordered before the store (though they still cannot be reordered before the load). – Nate Eldredge Jul 31 '22 at 14:57
  • 1
    If you really need to prevent something from being reordered before a store, AFAIK your only recourse is to use seq_cst on *both* the store and the other operation. Nothing weaker suffices in the C++ memory model. – Nate Eldredge Jul 31 '22 at 14:59

0 Answers0