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: in ref/mem explicitly use "buffered" when describing the rule for sends on channels #30120

Closed
odeke-em opened this issue Feb 7, 2019 · 6 comments

Comments

@odeke-em
Copy link
Member

odeke-em commented Feb 7, 2019

Just while studying the memory model at https://golang.org/ref/mem#tmp_7, I noticed a perhaps minor ambiguity in description.

Problem statement

We say "A send on a channel happens before the corresponding receive from that channel completes." [1]

and that's correct for buffered channels and the quoted program is guaranteed to print "hello, world"

var c = make(chan int, 10)
var a string

func f() {
	a = "hello, world"
	c <- 0
}

func main() {
	go f()
	<-c
	print(a)
}

However for unbuffered channels, we say "A receive from an unbuffered channel happens before the send on that channel completes." [2]

var c = make(chan int)
var a string

func f() {
	a = "hello, world"
	c <- 0
}

func main() {
	go f()
	<-c
	print(a)
}

the receive <-c is firstly encountered and will block until a corresponding send completes as we do in c <- 0 so that program is also guaranteed to print "hello, world" for unbuffered channels.

So while regardless of the first statement, the results are technically the same, it seems odd to vaguely keep a generalization[1] and a dictation[2] thereby alluding to two states existing for unbuffered channels (this is only because a receive has to be matched by a send for unbuffered channels) whereas buffered channels have a capacity to dictate their sends-first hence sends preceding receives.

Recommendation

My recommendation is that perhaps let's update the first rule to "A send on a buffered channel happens before the corresponding receive from that channel completes." [1] or perhaps I just need to catch some sleep.

Please feel free to chime in, your ideas/corrections are highly appreciated!

/cc @griesemer @robpike @rsc

@robpike
Copy link
Contributor

robpike commented Feb 8, 2019

It is correct as written.

@bcmills
Copy link
Contributor

bcmills commented Feb 28, 2019

Note that happens-before, despite the name, is a non-strict order: for unbuffered channels, the send happens before the receive and the receive happens before the send (that is, from the perspective of the memory model they are simultaneous).

@bcmills bcmills closed this as completed Feb 28, 2019
@go101
Copy link

go101 commented Mar 1, 2019

happens-before should be a strict order. The docs says A send on a channel happens before the corresponding receive from that channel completes. The word completes is very important here.

For an unbuffered channel, the send and the receive both happens before the send and the receive from that channel completes, In fact the the completions of the send and the receive are the same event.

@ianlancetaylor
Copy link
Contributor

ianlancetaylor commented Mar 1, 2019

You're using a different meaning of the word "strict." In mathematics, a "strict order" implies that there is a relationship between all pairs of objects. That is not true for the happens-before relationship, in which you can have A happens-before C and B happens-before C but there is no happens-before relationship between A and B.

@go101
Copy link

go101 commented Mar 1, 2019

Yes.

In the description (For an unbuffered chanel) A send on a channel happens before the corresponding receive from that channel completes., there are four events

  1. send start (call it A)
  2. receive start (call it B)
  3. send end/complete (call it C)
  4. receive end/complete (call it D)

I agree there is not specified order between A and B. But A and B are both guaranteed to happen before C and D. And in fact, C and D are the same event.

@go101
Copy link

go101 commented Mar 1, 2019

What I mean is the docs is accurate here.

@golang golang locked and limited conversation to collaborators Feb 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants