Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Jorropo opened this issue Jun 11, 2022 · 4 comments
Open

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

Jorropo opened this issue Jun 11, 2022 · 4 comments
Labels
Documentation NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@Jorropo
Copy link
Member

Jorropo commented Jun 11, 2022

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
Copy link
Member Author

Jorropo commented Jun 11, 2022

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

@ianlancetaylor
Copy link
Contributor

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
Copy link
Contributor

CC @rsc

@Jorropo
Copy link
Member Author

Jorropo commented Jun 11, 2022

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)

@thanm thanm added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 14, 2022
@seankhliao seankhliao added this to the Unreleased milestone Aug 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants