The atomic store will force a memory barrier - as long as the reader (in the other process) atomically reads the “new value”, all other writes prior will also be visible.
BUT you can still have an inter-process race condition if you are updating the same memory mapped file regions - and you need an OS mutex to protect against this, or use other advanced append/sequence number techniques. You can look at projects like https://github.com/OpenHFT/Chronicle-Queue <https://github.com/OpenHFT/Chronicle-Queue> for ideas. Still, large-scale shared memory systems are usually not required. I would use a highly efficient message system like Nats.io <http://nats.io/> and not reinvent the wheel. Messaging systems are also far more flexible. > On Jan 22, 2023, at 11:11 AM, Peter Rabbitson <ribasu...@gmail.com> wrote: > > > > On Sun, Jan 22, 2023 at 5:49 PM Ian Lance Taylor <i...@golang.org > <mailto:i...@golang.org>> wrote: > On Sat, Jan 21, 2023, 11:12 PM Peter Rabbitson (ribasushi) > <ribasu...@gmail.com <mailto: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 <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 <https://go.dev/play/p/ZXMg_Qq3ygF> ) > > > 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. > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAMrvTSL%2B5XO%3Dz6815RN6sNxLJsce%2BJsyRYm3zq85NiA6L9O_cA%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAMrvTSL%2B5XO%3Dz6815RN6sNxLJsce%2BJsyRYm3zq85NiA6L9O_cA%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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/5397AB07-C4E5-45B4-A3B4-785DEC7EEDB6%40ix.netcom.com.
