On Sun, Jan 22, 2023 at 7:39 PM robert engels <reng...@ix.netcom.com> wrote:
> 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. > Could you translate this to specific go code? What would constitute what you called "the atomic store" in the playground example I gave? > 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 > Correct. This particular system is multiple-reader single-threaded-writer, enforced by a Fcntl POSIX advisory lock. Therefore as long as I make the specific writer consistent - I am done. > You can look at projects like 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 and not reinvent the > wheel. Messaging systems are also far more flexible. > > Nod, the example you linked is vaguely in line with what I want. You are also correct that reinventing a wheel is bad form, and is to be avoided at all costs. Yet the latency sensitivity of the particular IPC unfortunately does call for an even rounder wheel. My problem isn't about "what to do" nor "is there another way", but rather "how do I do this from within the confines of go". -- 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/CAMrvTS%2BHqsqCOMay3c8D5LuTwcmtuZQJY7gs8Rw5rXBLiYwErg%40mail.gmail.com.
