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
Comments
It is correct as written. |
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). |
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. |
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. |
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
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. |
What I mean is the docs is accurate here. |
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"
However for unbuffered channels, we say "A receive from an unbuffered channel happens before the send on that channel completes." [2]
the receive
<-c
is firstly encountered and will block until a corresponding send completes as we do inc <- 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
The text was updated successfully, but these errors were encountered: