On Sun, Sep 8, 2019, 17:14 changkun <euryugas...@gmail.com> wrote: > Intuitively, the close statement should happens-before select statement > that starts choosing which case > should be executing, and select a closed channel with the highest priority > to prevent another receive case being executed once more. >
I don't really understand.ehat you mean by "intuitively" here. First: The close *does* happen-before the case clause of the select for the closed channel, as per the memory model. Second: If you actually establish an ordering "close happens-before the select statement, which happens-before the ticker firing", you should actually get the result you want, in that only the close-case is deterministically chosen, AIUI. So we are only talking about the case you tried to enforce, where you *don't* have that ordering - that is, where the close happens concurrently with the ticker firing and both happen concurrently to the select starting to execute. Now, ISTM that the simplest intuitive interpretation of what "event A and B happen concurrently" (defined abstractly as "are not ordered in the happens-before partial order) is that the order that A and B happen in real time in is unclear and could happen either way olin practice. And under that intuitive understanding, I don't know how you conclude that the select should prioritize either or not execute the ticker case at all. After all - you can never know whether the ticker *has actually fired* at the concrete real point in time the select executed. Note, by the way, that the fact that you observe either result doesn't actually say anything about the pseudo-randomness or lack thereof of the select statement: You can't, from the output of the program, distinguish between "both cases where ready to proceed and select flipped a coin coming up close" from "only close was ready to proceed, because select executed in between the closing/firing" (and the same for the timer firing). The pseudo-randomness of select is irrelevant for your case, it's the fact that these events are concurrent, both as specified and IMO as intuitively obvious. > My questions are: > Does the Go team or anybody else think of this memory order before? What > was the decision that didn't make it? > If not, is it worth to be defined within the language? There are no > language changes and only affects the runtime implementation. > > > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/6992b605-ff10-4659-8016-dd96066d4588%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/6992b605-ff10-4659-8016-dd96066d4588%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEFW0ZRs7HRvX4MNe7YYMmj%2BBYskoviQAhkZHMJf%3D0S2w%40mail.gmail.com.
