doc: go_mem.html is unclear about io as synchronisation mechanism

[Jorropo]

https://tip.golang.org/ref/mem does not speak about os operations.

Is a syscall a synchronization primitive if the underlying os says the corresponding syscall is ?

In other words:

var shared int

func read(print, close *os.File) {
  print.Read() // wait EOF
  fmt.Println(shared)
  close.Close() // send EOF
} 

func main() {
  printr, printw, err := os.Pipe()
  c(err)
  closer, closew, err := os.Pipe()
  c(err)

  go read(printr, closew)
  shared = 42
  printw.Close() // send EOF
  closer.Read() // wait EOF
}

Legal code ? (assuming posix) Please ignore the fact that this code is completely unrealistic, this could realistically come up in edge cases of real code.

[Jorropo]

This is at least an assumption the runtime do, since it uses futex on posix.

[ianlancetaylor]

I think this is out of scope for the Go memory model documentation. I would be interested to hear whether the memory model documentation for any other language covers this. In particular, I certainly don't think the Go memory model should start listing system calls.

Note that the way that the runtime package uses futex does not need to be described in the Go memory model. The runtime package is responsible for implementing the memory model. It doesn't have to rely on the memory model itself.

[ianlancetaylor]

CC @rsc

[Jorropo]

In particular, I certainly don't think the Go memory model should start listing system calls.

Yes certainly. I'm thinking of a sentence like:

If the underlying os garentee that a some syscall sequence with some observable effect has synchronising behaviour, then performing and observing it is a synchronisation following the os's contract.

(Should be reworded better i think)