Hi John, they are equivalent. I chose to not indent the second select. Your comment on the call to next being concurrent is the exact point of this program. It reveals the race condition between the first and second select and demonstrates that even if hi and lo are both ready, or hi became ready first, the receive on lo can be satisfied first.
Val, the *send* on hi happens before the *send* on lo with the current compiler. I am pretty sure the compiler will currently not reorder these, there is no reason. Yes, a theoretical compiler could, but for this example, the demonstration that this is not deterministic, it is good that the compiler does not reorder the events. This test case is to demonstrate the even if a send happens on the hi channel before a send happens on the lo channel, the next function may still decide to process the event from the lo channel as both sends happened between the first and second select. Thus the fact that this is not deterministic is no longer theory, but empirical. I believe from the OP's standpoint, they would have wanted the receive on hi to always be the selected one. BTW, by the definition of determinism, it is not possible to have two events happen at once and that either of them may be considered first. That is a nondeterministic program. A deterministic program always produces the same results each time it is run. On Wed, Jan 25, 2017 at 3:02 PM, John Souvestre <j...@souvestre.com> wrote: > I believe that there is a typo in your example. It seems that you have > separate selects instead of nested selects. > > > > Try: https://play.golang.org/p/YWYhnLJsdS > > > > John > > John Souvestre - New Orleans LA > > > > *From:* Paul Borman [mailto:bor...@google.com] > *Sent:* 2017 January 25, Wed 16:01 > > *To:* John Souvestre > *Cc:* golang-nuts > *Subject:* Re: [go-nuts] Re: Priority cases in select? > > > > I originally was thinking on the lines of what John said, but I proved it > wrong, see https://play.golang.org/p/JwX_cxaR99 for the code. You can't > run it in the playground, but on my MacPro I get output like: > > > > $ GOMAXPROCS=1 go run r.go > > Failed after 1137702 > > Failed after 699376 > > Failed after 757658 > > ^Csignal: interrupt > > $ GOMAXPROCS=2 go run r.go > > Failed after 12954 > > Failed after 63778 > > Failed after 11831 > > Failed after 277038 > > ^Csignal: interrupt > > > > So even though hi was clearly written before lo, it is possible to fail > the first select, have hi and lo written (in that order), and then enter > the second select which has a 50% chance on reading from lo, even with > GOMAXPROCS set to 1. > > > > On Wed, Jan 25, 2017 at 11:27 AM, John Souvestre <j...@souvestre.com> > wrote: > > I understand what you are saying, but all of these situations are > basically race conditions, aren’t they? So there is no deterministic > manner of resolving them. Thus it doesn’t matter which is chosen. > However, in the more general, non-race, condition I believe that it meets > the goals. > > > > John > > John Souvestre - New Orleans LA > > > > *From:* Axel Wagner [mailto:axel.wagner...@googlemail.com] > *Sent:* 2017 January 25, Wed 13:19 > *To:* John Souvestre > *Cc:* golang-nuts > *Subject:* Re: [go-nuts] Re: Priority cases in select? > > > > Doesn't work. If no communication can proceed when entering the select, > this degenerates to a simple select. For example, say there are no writers > to any of those channels. At the same time, that the last select is > entered, three different goroutines start blocking to write to one of the > channels each. Even though priorityHigh could proceed, you will read from > one of the other with ⅔ probability. > > > > (a simpler case: Imagine that, while the goroutine is blocking in the > innermost select, a second goroutines enters *the same* select, just with > writes. Semantically, all three communications can proceed at the same time > for both goroutines, so one is chosen uniformly) > > > > This is the fundamental problem with all the nested select solutions; they > assume that the code is evaluated atomically. But in reality, the state of > a communication being possible can change at any point for an arbitrary > number of channels. Thus, you can always construct a sequence where you > revert to the innermost select, violating c. > > -- > 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. > > > > -- > 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. > -- 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.
smime.p7s
Description: S/MIME Cryptographic Signature
