torsdag 6. mai 2021 kl. 21:41:11 UTC+2 skrev ren...@ix.netcom.com: > 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. > > 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. >
For a [0] dim unbuffered chan there should be no need for any buffer, unless (as you say, there is some network in between). Basically a channel consists of which task was "first" on it, what it wants to do and a pointer to the data and the len, when the first part is descheduled until after the second part on the channel is ready, the action is done (a *memcpy* in the correct direction, from local data inside one task to local data in the other task, this is 100% safe and there is no need for semaphores etc. to protect anything) and the first part is set to become rescheduled. This means that a synchronous unbufferd channel has no buffer and no queue for the data. And as Rob Pike said "Now for those experts in the room who know about *buffered channels* in Go – which exist – you can create a channel with a buffer. And buffered channels have the property that they don’t synchronize when you send, because you can just drop a value in the buffer and keep going. So they have different properties. And they’re kind of subtle. They’re very useful for certain problems, but *you don’t need them*. And we’re not going to use them at all in our examples today, because I don’t want to complicate life by explaining them.” (https://www.youtube.com/watch?v=f6kdp27TYZs) Øyvind > > 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/11e7d795-d2b7-416c-b860-6fa650d2d5f9n%40googlegroups.com.
