On Saturday, October 28, 2017 at 4:56:42 PM UTC-4, T L wrote: > > 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. >
typos here, it should be then the statements shown before event A in source code will be executed before event B, and the statements shown after event B 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> 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. >>> 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.
