torsdag 6. mai 2021 kl. 22:15:14 UTC+2 skrev axel.wa...@googlemail.com:
> To clarify again: As a litmus test, a `select` construct like the one I'm > talking about would mean that this code blocks forever: > https://play.golang.org/p/LcWgDcX5ojl > With the current `select`, it doesn't. With a different `select`, which > uses source order to express priority and under the semantics I'm asking > about, this would always block, because `lo` would never be read. > I don't know if one would use a pri select to pick up channels from the same task. Here's a mod that seems to behave wildly differently when the channels are signalled from one task each and those two tasks are swapped in order. How may that be explained? I would have suggested the same log trail for both: https://play.golang.org/p/lJA0XPWtj-w Øyvind > > On Thu, May 6, 2021 at 10:05 PM Axel Wagner <axel.wa...@googlemail.com> > wrote: > >> >> >> On Thu, May 6, 2021 at 9:40 PM Robert Engels <ren...@ix.netcom.com> >> wrote: >> >>> But that is not really true because there are no constraints on if the >>> source channels are buffered - if they are then my code operates similarly. >>> >> >> I was very clear. I was asking if it is possible to implement a priority >> select with the semantics "if the high priority case becomes ready before >> the low priority case, it always takes the high priority case". Saying "but >> what if we try to ensure that both of them are always ready" is not >> answering the question. >> Please stop insisting that the code you provide solves this. It simply >> doesn't. Given that I phrased the question, I feel justified in claiming >> the authority if it does or not. >> >> >>> Even if using unbuffered channels there is buffering being done at a >>> lower level (hardware buffers, network stack buffers, etc) - so not >>> “unblocking a sender” is a dubious endeavor. >>> >> >> That is how select behaves, though. It chooses a communication to proceed >> (currently, uniformly at random, under the premise of the question, the >> highest priority one) and lets that proceed. >> >> If you don't have an answer to the question I posed, it is okay to just >> not answer it. If there is no answer, that's okay too. But arguing about >> code which clearly does not answer it is frustrating. >> >> >>> >>> >> >>> On May 6, 2021, at 1:30 PM, 'Axel Wagner' via golang-nuts < >>> golan...@googlegroups.com> wrote: >>> >>> >>> On Thu, May 6, 2021 at 8:22 PM Robert Engels <ren...@ix.netcom.com> >>> wrote: >>> >>>> “If lo” means that if the lo channel was read. >>>> >>> >>> Exactly. To fulfill the requirements and answering the question, it must >>> not be read. >>> >>> This code will prevent a lo from being processed if a hi is available at >>>> the happens before moment of a value being ready. >>>> >>> >>> What the receiver does with the value is immaterial. Point is, that the >>> receiver has already read the value, thus the communication has happened, >>> thus the sender was unblocked. The question is about a select that wouldn't >>> do that. >>> >>> >>>> Btw using indents rather than brackets in the above - maybe that is >>>> causing the confusion. >>>> >>> >>> I'm not confused. Your code is simply not answering the question posed. >>> Which is about a select which always lets the high priority communication >>> happen, if it is ready before the low priority communication - and >>> consequently *doesn't* let the low priority communication happen. >>> >>> >>>> >>>> >>>> >>>> On May 6, 2021, at 12:37 PM, 'Axel Wagner' via golang-nuts < >>>> golan...@googlegroups.com> wrote: >>>> >>>> >>>> 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 <ren...@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 < >>>>> golan...@googlegroups.com> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, May 6, 2021 at 4:43 PM roger peppe <rogp...@gmail.com> wrote: >>>>> >>>>>> >>>>>> On Thu, 6 May 2021 at 14:41, 'Axel Wagner' via golang-nuts < >>>>>> golan...@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.wa...@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...@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...@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...@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 >>>> >>>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHv2cKR1OLS97YN7JYKZXHu_s0a-6c0-2tW%3DS0gUU8jUA%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...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHQq2p60OenLMYUFz%3DK9HigpbAqj7m%3D%2BRp7BnCX%2Bp1QLA%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHQq2p60OenLMYUFz%3DK9HigpbAqj7m%3D%2BRp7BnCX%2Bp1QLA%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/b5dcb025-7cea-4f11-a7fc-8217b06ade59n%40googlegroups.com.
