You are correct; I was ignoring the second edge specified later. So in some sense, for unbuffered channels, the edge is bidirectional. You still can't ignore the fact that channel operations create an edge between two and only two specific goroutines. And your initial wording is an oversimplification, because it ignores that.
On Sat, Oct 28, 2017 at 3:26 PM, T L <tapir....@gmail.com> wrote: > > > On Saturday, October 28, 2017 at 9:24:56 AM UTC-4, T L wrote: >> >> >> >> On Saturday, October 28, 2017 at 8:45:00 AM UTC-4, Axel Wagner wrote: >>> >>> No. The channel operations do not act like a fence, but like a… channel, >>> through which happens-before relationships can be transported. The crucial >>> point in the example you quoted is, that the channel-communication creates >>> a happens-before relationship between the two goroutines, which then >>> connects the happens-before relationships between channel-send/write and >>> channel-read/print. >>> >>> Let's say, hypothetically, the happens-before relationship for >>> channel-operations was turned around: The read happens before the send. >>> Conceptually, they happen simultaneously and just from a local perspective, >>> both operations would still look just as much as a "fence". But suddenly, >>> there wouldn't be a happens-before relationship between the write and the >>> print: >>> write ≤ channel-send ≥ channel-read ≤ print >>> >> >> There is not a constant order between the send and the receive. >> For an unbufferred channel, the guaranteed orders include: >> 1. the send must happen before the completion of the receive, >> 2. the receive must happen before the completion of the send. >> In other words, the completion of the receive and the the completion of >> the send happen at the same time, >> they should be viewed as the same event. Both of the send and receive >> happen before the event. >> So, at least for the two involved goroutines, the completion event must >> act as a fence to guarantee the memory model. >> >> In theory, the completion event is able to NOT act as a fence. >> But I just doubt if it is possible from the implementation view. >> > > Here, I mean "In theory, the completion event is able to NOT act as a > fence *for other goroutines*. But I just doubt if it is possible from the > implementation view." > > >> >> >>> >>> You *have* to look at relationships between goroutines. And you need >>> (or rather it's incredibly sensible) to take the causality-lens when >>> understanding the memory model; it was chosen for a reason. The memory >>> model is about establishing causal relationships between events in >>> different goroutines and about the direction of that causality. It only >>> makes promises about what GR A observes about GR B *if* there is an >>> edge between them and only *if* that edge is correctly oriented. >>> >>> On Sat, Oct 28, 2017 at 1:45 PM, T L <tapi...@gmail.com> wrote: >>> >>>> The first example in the "Channel communication" section, it says >>>> >>>> The write to a happens before the send on c, which happens before the >>>> corresponding receive on c completes, which happens before the print. >>>> >>>> From the description, I feel that "the write to a happens before the >>>> send on c" is not caused by >>>> "the send on c happens before the corresponding receive on c >>>> completes". >>>> And "the corresponding receive on c completes happens before the print" >>>> is also independent to >>>> "the send on c happens before the corresponding receive on c >>>> completes". >>>> >>>> So it looks channel read and write operations really act as a fance to >>>> avoid exchanging relative orders of statements before and after the fence. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "golang-nuts" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to golang-nuts...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
