fredag 7. mai 2021 kl. 21:10:39 UTC+2 skrev axel.wa...@googlemail.com:
> On Fri, May 7, 2021 at 8:49 PM Øyvind Teig <oyvin...@teigfam.net> wrote: > >> 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 >> > > It does seem to make a difference, but that's mainly due to coincidences > of the implementation. I assume it has something to do with how the newly > created goroutines are scheduled - you do start one after the other and > maybe, for some implementation specific detail, it tends to schedule the > last one first. > > Either way, you can't rely on that behavior. From a pure spec and memory > model POV, both programs provide you the same behavioral guarantees. > Agree. But if a behavioural guarantee doesn't behave, then it leaves me just staring out on the sky that's blue 35 minutes more.. Øyvind > > > >> >> Ø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...@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 >> >> <https://groups.google.com/d/msgid/golang-nuts/b5dcb025-7cea-4f11-a7fc-8217b06ade59n%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/99c84dd1-91ea-4eeb-84a1-e4061f0507e3n%40googlegroups.com.
