On Saturday, October 28, 2017 at 2:18:05 PM UTC-7, T L wrote: > > > > 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. >> 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. >> > > I think > > If event A happens before event B, then any of the goroutines involved in > the two events > will observe that any of the statements shown before event A in source > code will be executed > before any of the statements shown after event B in source code. > > is better than > > The write to a happens before the send on c, which happens before the > corresponding receive on c completes, which happens before the print. > > I do like your wording. Your description is certainly more operational (directly useful to Go programmers). I would expect a statement like that in a how-to, but probably not in the spec. Your wording can be derived from the spec and the transitivity of happens-before. Your description isn't sufficient though, because it doesn't describe things like goroutine 1 sending on a channel to goroutine 2, when then sends on a channel to goroutine 3. So I think you'd still need the spec description anyway. The partial order, across any number of goroutines and any number of synchronization operations, is the fundamental underlying abstraction. That's why the spec uses it.
> >> >> 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.
