Just to be clear, to get what you want just write data normally for steps 1-4 and use an atomic store for step 5. That guarantees that other processes will see steps 1-4 all done if they see the write from step 5. (But you *do* have to use an atomic read appropriate to your language to do reader step 1. Just a standard read will not do.)
Go does not provide separate "pure" memory barriers. The compiler and/or runtime include them when needed to ensure the required semantics for locks, atomic operations, etc. On Monday, January 23, 2023 at 2:13:20 AM UTC-8 Gergely Födémesi wrote: > On 1/23/23, Peter Rabbitson <riba...@gmail.com> wrote: > ... > > I guess I will spend some time to learn how to poke around the generated > > assembly tomorrow... > > If I understand correctly you are trying to force your model of the > world into the Go memory model. The models are different, so this > won't work. > > Please also note that your model of current execution complexes is > probably valid today, but it could change anytime. The Go memory model > is differently restricting to accommodate for that future. > > Of course you can implement what you want using any tool available, > but the correct execution can't be ensured by the Go memory model if > you don't build on that. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3272b1ce-e976-4c0f-9813-985cbd5f364an%40googlegroups.com.
