On Sun, Jan 22, 2023 at 9:12 AM Peter Rabbitson <ribasu...@gmail.com> wrote: > > On Sun, Jan 22, 2023 at 5:49 PM Ian Lance Taylor <i...@golang.org> wrote: >> >> On Sat, Jan 21, 2023, 11:12 PM Peter Rabbitson (ribasushi) >> <ribasu...@gmail.com> wrote: >>> >>> This question is focused exclusively on the writer side. >> >> >> Perhaps I misunderstand, but it doesn't make sense to ask a question about >> the memory model only about one side or the other. The memory model is >> about communication between two goroutines. It has very little to say about >> the behavior of a single goroutine. > > > I might be using the wrong term then, although a lot of text in > https://go.dev/ref/mem is relevant, it just does not answer my very specific > question. Let me try from a different angle: > > I want to write a single-threaded program in go which once compiled has a > certain behavior from the point of view of the OS, . More specifically this > program, from the Linux OS point of view should in very strict order: > 1. grab a memory region > 2. write an arbitrary amount of data to the region's end > 3. write some more data to the region start > > By definition 1) will happen first ( you got to grab in order to write ), but > it is also critical that the program does all of 2), before it starts doing > 3). > > Modern compilers are wicked smart, and often do emit assembly that would have > some of 3) interleaved with 2). Moreover, due to kernel thread preemption 2) > and 3) could execute simultaneously on different physical CPUs, requiring a > NUMA-global synchronization signal to prevent this ( I believe it is LOCK on > x86 ). I am trying to understand how to induce all of this ordering from > within a go program in the most lightweight manner possible ( refer to the > problem statement and attempts starting on line 38 at > https://go.dev/play/p/ZXMg_Qq3ygF )
Memory ordering only makes sense in terms of two different execution threads using shared memory. In order to answer your question precisely, you need to tell us what the process reading the memory region is going to do to access the memory. In order to know how to write the memory, it's necessary to know how the memory is going to be read. That said, it's fairly likely that if you use an atomic store for the very first memory write in step 3 that the right thing will happen. On the Go side, that will ensure that all memory operations before that memory write have at least been executed. And if the reader does an atomic read, it should ensure that when the reader sees that memory write, it will also see all the earlier memory writes. > > If I were in C-land I believe would use something like: > > #include <asm/system.h> > > void wmb(void); > > > The question is - what is the go equivalent. There is no Go equivalent to a pure write memory barrier. Of course you could use cgo to call a C function that does exactly what you want. Ian -- 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/CAOyqgcWGteeF9HqyygEmXUiGW3KYxWDQpaP5dQJBkNiy4D1s%2BQ%40mail.gmail.com.
