In my opinion, the memory model article should mention that if event A happens event B, the the statements shown before event A in source code will be executed before event B, and the statements shown after event A in source code will be executed after event A. Otherwise the description "The write to a happens before the send on c, which happens before the corresponding receive on c completes, which happens before the print. " is some abrupt.
On Saturday, October 28, 2017 at 1:35:37 PM UTC-4, Axel Wagner wrote: > > The thing is: The memory model *is for academics*. It is for compiler > authors and people working on low-level primitives. As the author of a > regular Go package or Go program, the only sentence from the memory model > that should be of relevance to you, is > > If you must read the rest of this document to understand the behavior of >> your program, you are being too clever. > > > which is why I quoted it several times. And you could even write a > conforming Go implementation without needing to refer to the memory model > at all. > > All of that being said: I am biased, because I have a Math and CS degree. > But, personally, I don't find the notion of a partial order > <https://en.wikipedia.org/wiki/Partially_ordered_set#Formal_definition> *that > *academic or hard to understand. It should be pretty commonly understood > by most programmers, TBQH, and the rest should be able to grasp it > relatively quickly from a couple of examples. > > All the memory model really does, is a) define a partial order called > "happens-before" and b) tell you how this translates into possible and > guaranteed observed behavior. > > > On Sat, Oct 28, 2017 at 5:11 PM, T L <tapi...@gmail.com <javascript:>> > wrote: > >> 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> 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. >>>> 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.
