4 ms·

The Go runtime has quite a few places where it assumes atomic load/store behavior of int sized words as well as the eventual propagation of the stores. I alway

The Go runtime has quite a few places where it assumes atomic load/store behavior of int sized words as well as the eventual propagation of the stores. I always get a little anxious when looking at such code. But it seems to work well in practice?

colesbury 3y ago
Go's memory model is more constrained than C, C++, and Swift and this case is specifically addressed: https://go.dev/ref/mem#restrictions https://go.dev/ref/mem#restrictions. "...each read of a single-word-sized or sub-word-sized memory location must observe a value actually written to that location"
- felixge 3y ago
  Yeah, but there is no guarantee that a write of one goroutine will eventually become visible to other goroutines. So in practice the runtime expects stronger guarantees.
  - colesbury 3y ago
    Memory models don't usually explicitly guarantee that writes "eventually become visible". They're usually written as ordering guarantees for when a write becomes visible, such as happens-before relationships. Obviously, for multithreaded programs to be useful, the writes have to eventually become visible to other threads/groroutines just like you want all sorts of other operations to happen in finite time that are not explicitly guaranteed by standards (like whether a thread/goroutine eventually starts.)
    - felixge 3y ago
      Well said. But how much finite time are we talking about (for writes to become visible)? Does it differ between architectures? Can there be extreme edge cases?
compiler-guy 3y ago
Anyone who writes a compiler for Go can guarantee such behavior--anything else is a buggy implementation. It works in practice because it's a requirement of the implementation.
- felixge 3y ago
  I guess I’m less worried about the atomic nature of the operation and more about the way the writes become visible. That seems to be entirely hardware dependent?

colesbury 3y ago

Go's memory model is more constrained than C, C++, and Swift and this case is specifically addressed: https://go.dev/ref/mem#restrictions https://go.dev/ref/mem#restrictions. "...each read of a single-word-sized or sub-word-sized memory location must observe a value actually written to that location"

felixge 3y ago
Yeah, but there is no guarantee that a write of one goroutine will eventually become visible to other goroutines. So in practice the runtime expects stronger guarantees.
- colesbury 3y ago
  Memory models don't usually explicitly guarantee that writes "eventually become visible". They're usually written as ordering guarantees for when a write becomes visible, such as happens-before relationships. Obviously, for multithreaded programs to be useful, the writes have to eventually become visible to other threads/groroutines just like you want all sorts of other operations to happen in finite time that are not explicitly guaranteed by standards (like whether a thread/goroutine eventually starts.)
  - felixge 3y ago
    Well said. But how much finite time are we talking about (for writes to become visible)? Does it differ between architectures? Can there be extreme edge cases?

compiler-guy 3y ago

Anyone who writes a compiler for Go can guarantee such behavior--anything else is a buggy implementation. It works in practice because it's a requirement of the implementation.

felixge 3y ago
I guess I’m less worried about the atomic nature of the operation and more about the way the writes become visible. That seems to be entirely hardware dependent?