Maybe some of my confusions come from the fact that some descriptions in the Go 1 memory model article are too academic. And the article also doesn't cover some order guarantees in Go.
On Saturday, October 28, 2017 at 10:38:19 AM UTC-4, Axel Wagner wrote: > > 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 <tapi...@gmail.com <javascript:>> > 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...@googlegroups.com <javascript:>. >> 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.
