On Saturday, October 28, 2017 at 7:55:22 PM UTC-4, Keith Randall wrote: > > > > 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. > > yes, find a perfect wording is hard. I often found thirdparty go articles are full of inaccurate descriptions. Maybe, for spec, the more conservative, the better.
> > >> >>> >>> 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.
