On Mon, Jan 23, 2023 at 10:54 PM Ian Lance Taylor <i...@golang.org> wrote:
> There is a model of memory behavior in which programs use pure write > memory barriers and pure read memory barriers. However, Go does not > use that model. Go uses a different model, in which writers and > readers are expected to cooperate using atomic loads and stores. > Understood. Thank you (and Keith) for stating this enough times that it clicked for me: it's not that what I am trying to do is impossible, but rather there is nothing in go that exposes these types of barriers to userspace by design. Having this mentioned explicitly in the memory model doc would have helped me build the correct frame of reference early on. > As such, Go does not provide a pure write memory barrier. I promise. > (As I noted earlier, Go does permit calling into C, and therefore > permits you to do anything that C permits you to do. It's worth > noting that because C code can do anything, a call into a C function > is a full compiler (but not hardware) memory barrier.) > The CGO compile-time ergonomics overhead is a bit of a concern in my case. Does calling into non-inlineable(?) go-asm functions achieve the same compiler-ordering-barrier? I.e. is the following kosher / reasonably forward-compatible: https://stackoverflow.com/q/42911884 ? Thank you! -- 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/CAMrvTSKdom%2Bvj7eOF3s4GLz-cT35vobyoCvtg2qL%3DfPPD1ESRw%40mail.gmail.com.
