No, it is not. Your "if lo" branch implies that the communication happened - e.g. the sender was already unblocked. A `select` would not unblock the other side unless that's the actual branch taken.
On Thu, May 6, 2021 at 7:32 PM Robert Engels <reng...@ix.netcom.com> wrote: > I already showed you - just change it to > > Select hi > Default: > Select hi,lo > If lo: > Select hi > Default : > Pass > > And enqueue the lo if a hi and lo are read. > > That is all that is needed. > > > > On May 6, 2021, at 10:28 AM, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > > > > > On Thu, May 6, 2021 at 4:43 PM roger peppe <rogpe...@gmail.com> wrote: > >> >> On Thu, 6 May 2021 at 14:41, 'Axel Wagner' via golang-nuts < >> golang-nuts@googlegroups.com> wrote: >> >>> PS: And I'm not saying there is no argument. Maybe "select is not >>> atomic" is such an argument. But if there is an argument and/or if this is >>> that argument, I don't fully understand it myself. >>> >> >> One reason is that the semantics can conflict. Consider this code, for >> example (assuming a hypothetical "pri select" statement that chooses the >> first ready arm of the select) - the priorities conflict. I suspect Occam >> doesn't encounter that issue because it only allows (or at least, it did >> back when I used Occam) select on input, not output. I believe that >> restriction was due to the difficulty of implementing bidirectional select >> between actual distributed hardware processors, but I'm sure Øyvind knows >> better. >> >> func main() { >> c1, c2, c3 := make(chan int), make(chan int), make(chan int) >> >> go func() { >> pri select { >> case c1 <- 1: >> case v := <-c2: >> c3 <- v >> } >> }() >> go func() { >> pri select { >> case c2 <- 2: >> case v := <-c1: >> c3 <- v >> } >> }() >> fmt.Println(<-c3) >> } >> > > Interesting case. I would argue, though, that there is no happens-before > edge here to order the cases and I was only considering providing a > guarantee if there is one. > > >> That said, I suspect that the semantics could be ironed out, and the real >> reason for Go's lack is that it's not actually that useful; that it would >> be one more feature; and that in practice a random choice makes sense >> almost all the time. >> > > As I said, this would certainly satisfy me as an answer :) > > >> >> >> On Thu, May 6, 2021 at 3:40 PM Axel Wagner <axel.wagner...@googlemail.com> >>> wrote: >>> >>>> FWIW after all this discussion I *am* curious about a more detailed >>>> argument for why we can't have a priority select that guarantees that >>>> *if* the high-priority case becomes ready before the low-priority one >>>> (in the sense of "there exists a happens-before edge according to the >>>> memory model"), the high-priority will always be chosen. >>>> >>>> That is, in the example I posted above >>>> <https://play.golang.org/p/UUA7nRFdyJE>, we *do* know that `hi` >>>> becoming readable happens-before `lo` becoming readable, so a true >>>> prioritized select would always choose `hi` and never return. The construct >>>> we presented *does* return. >>>> >>>> Now, I do 100% agree that it's not possible to have a select that >>>> guarantees that `hi` will be read if both *become readable >>>> concurrently*. But I don't see a *fundamental* issue with having a >>>> select that always chooses `hi` if `*hi` becoming readable >>>> happens-before `lo` becoming readable*. >>>> >>>> And to be clear, I also kinda like that we don't have that - I think >>>> the value provided by the pseudo-random choice in preventing starvation is >>>> worth not having an "ideal" priority select construct in the language. But >>>> I couldn't really make a good case why we *can't* have it. >>>> >>> -- >>> 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/CAEkBMfEJNtu1i1RyZxW5FNYkD0TB73nq0WyVCCW_E9_JOAVJmw%40mail.gmail.com >>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEJNtu1i1RyZxW5FNYkD0TB73nq0WyVCCW_E9_JOAVJmw%40mail.gmail.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/CAEkBMfHEEDdL8adBDFoqwVHswK3kr_KawePGi%3DNtbaBVTP5KWw%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHEEDdL8adBDFoqwVHswK3kr_KawePGi%3DNtbaBVTP5KWw%40mail.gmail.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/CAEkBMfHv2cKR1OLS97YN7JYKZXHu_s0a-6c0-2tW%3DS0gUU8jUA%40mail.gmail.com.