On Thu, Apr 29, 2021 at 10:47 PM Øyvind Teig <oyvind.t...@teigfam.net> wrote:
> > 1. I'm sorry I didn't follow up on your answer where you had got to > the length of spelling out some code right before my eyes. I got lost in > the other points (I actually started a response..) > 2. I trust you > 3. But to do more than trusting, understanding would be much better. > I'm sorry: to understand I would need more than pseudo code > 4. But I was really after whether the "pri" keyword (or whatever) in > front of "select" had been introduced over the last years. The answer seems > to be "no" > > FWIW I did answer this explicitly above :) No, there is no way to manually specify priorities of `select` and no, I subjectively wouldn't predict it happening at any point in the near or far future. Unless someone comes up with an extremely convincing, so far unheard of argument in its favor :) > > 1. Although I appreciate that Turing proved that any language can code > anything, I some times have had a hard time believing it. Maybe that's not > exactly what he meant. But then, since I trust you, I do find that solution > as surprising as as I would be happy to run it on The Go Playground > > torsdag 29. april 2021 kl. 22:02:23 UTC+2 skrev ren...@ix.netcom.com: > >> I already gave you the solution to this. Trust me it works. I did HFT for >> 7+ years - the algo is well known. >> >> On Apr 29, 2021, at 2:05 PM, Øyvind Teig <oyvin...@teigfam.net> wrote: >> >> >> >> torsdag 29. april 2021 kl. 20:22:32 UTC+2 skrev rog: >> >>> I agree with Axel's take here. It seems, Øyvind, that you are concerned >>> more with principle than practice here. Can you give an example of a real >>> world case where you think that this might actually matter? >>> >> >> Thanks, yes. I have written some about that in the *Nondeterminsim* blog >> note, referred to at the top. I admit I indicated that seeing some code >> might be interesting, but it was the principle I was after. In the end a >> "yes" or "no". >> >> Some from the chapter "*-Nondeterministic selective choice in >> implementations is not good*": (Preceeding the quote I have been telling >> about CSP's *external* nondeterministic choice in the *specfications* >> ("implement this any way you want") but in the *implementation* part we >> have to take decisions (deterministic, inner choice: "we do it *this* >> way"). I was thinking this is relevant because Why build concurrency on >> the ideas of CSP? <https://golang.org/doc/faq#csp> Here's the quote: >> >> *"The statement was that with the non-deterministic guarded choice in Go, >> what happens is up to the run-time, which is “not good”. This >> is implementation, not specification. With occam there is ALT or PRI ALT, >> always coded as PRI ALT. For a server to be “fair” I have to code it >> myself, it’s up to me, at the application level to find the best algorithm. >> Which, during my years as occam programmer was “new starting channel index >> in the ALT-set is the channel index of the served channel + 1 >> modulo-divided by number of channels”. Channels are clients[0..4] >> (five) ALT‘ed in set [4,0,1,2,3] served index 4, then 4+1 rem 5 == 0 yields >> next ALT set [0,1,2,3,4]. Just served 4 and you’re at the back of the set."* >> >> The example here is a server with N clients where it is essential that >> none of clients will starve and none jam the server. I have needed to do >> this coding several times. Go has random select which in theory may mean >> starving and jamming. I worked with safety critical fire detection, and it >> was necessary to ensure this. Or at least we didn't dare to take the >> chance. We could not just add another machine. >> >> To use select when that's fair enough (pun 1) - "fair enough" (pun 2). >> But If I want to be certain of no starving or jamming I need to code the >> fairness algorithm. I can then promise a client that may have been ready >> but wasn't served to come in before I take the previous clients that were >> allowed. This is at best very difficult if all we have is select. Having >> pri select as the starting point is, in this case, easier. >> >> Øyvind >> >> >>> >>> On Thu, 29 Apr 2021, 15:44 'Axel Wagner' via golang-nuts, < >>> golan...@googlegroups.com> wrote: >>> >>>> FWIW, maybe this helps: >>>> >>>> Assume a read happened from lowPriority, even though highPriority was >>>> ready to read as well. That's, AIUI, the outcome you are concerned about. >>>> >>>> In that situation, how would you know that highPriority was ready to >>>> read as well? >>>> >>>> On Thu, Apr 29, 2021 at 4:39 PM Axel Wagner <axel.wa...@googlemail.com> >>>> wrote: >>>> >>>>> On Thu, Apr 29, 2021 at 3:54 PM Øyvind Teig <oyvin...@teigfam.net> >>>>> wrote: >>>>> >>>>>> They could still both have become ready (not in the same "cycle") >>>>>> between the two selects. Even if that probability is low, it would need >>>>>> knowledge like yours to show that this may in fact be zero. There could >>>>>> be >>>>>> a descheduling in between, one of those in my opinion, not relevant >>>>>> arguments. >>>>> >>>>> >>>>> FTR, again: Yes, it's definitely possible, but it's irrelevant. It >>>>> makes no observable difference. Even if we had a prioritized select, it >>>>> would still be *de facto* implemented as a multi-step process and even >>>>> then, you might run into exactly the same situation - you could have both >>>>> channels becoming ready while the runtime does setup, or you could have a >>>>> random scheduling event delaying one of the goroutines infinitesimally, or >>>>> you could have… >>>>> >>>>> This is why we *don't* talk about the behavior of concurrent programs >>>>> in terms of cycles and time, but instead based on causal order. We don't >>>>> know how long it takes to park or unpark a goroutine, so all we can say is >>>>> that a read from a channel happens after the corresponding write. In terms >>>>> of time, between entering the `select` statement and between parking the >>>>> goroutine might lie a nanosecond, or a million years - we don't know, so >>>>> we >>>>> don't talk about it. >>>>> >>>>> The memory model is exactly there to abstract away these differences >>>>> and to not get caught up in scheduling and cycle discussions - so, FWIW, >>>>> if >>>>> these arguments are not relevant, you shouldn't bring them up. Logically, >>>>> between the first `select` statement and the second `select` statement, >>>>> there is zero time happening. Arguing that there is, is using exactly >>>>> those >>>>> irrelevant arguments about schedulers and processing time. >>>>> >>>>> >>>>>> torsdag 29. april 2021 kl. 15:47:42 UTC+2 skrev Jan Mercl: >>>>>> >>>>>>> On Thu, Apr 29, 2021 at 3:23 PM Øyvind Teig <oyvin...@teigfam.net> >>>>>>> wrote: >>>>>>> >>>>>>> > 4c is not "correct" as I want it. In the pri select case, if more >>>>>>> than one is ready, then they shall not be randomly chosen. Never. They >>>>>>> should be selected according to priority. >>>>>>> >>>>>>> That's not what 4c says. Instead of "more than one ready" it says >>>>>>> "both high and low _get ready at the same time_". >>>>>>> >>>>>>> Note that in the first approximation the probability of 4c happening >>>>>>> is approaching zero. If we consider time "ticks" in discrete quanta, >>>>>>> the probability is proportional to the size of the quantum. And >>>>>>> depending on a particular implementation of the scheduler the >>>>>>> probability of 4c can still be exactly zero. For example, the OS >>>>>>> kernel may deliver only one signal at a time to the process etc. >>>>>>> >>>>>>> So the "Never" case may quite well never happen at all. >>>>>>> >>>>>> -- >>>>>> 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/2460a16f-af1b-4613-ba4a-72b13e816a2bn%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/golang-nuts/2460a16f-af1b-4613-ba4a-72b13e816a2bn%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...@googlegroups.com. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFC1gtxbWZsy88gM4ymPncCjs6Q3YJpTcXym8bT1Ev6Kw%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFC1gtxbWZsy88gM4ymPncCjs6Q3YJpTcXym8bT1Ev6Kw%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/20c0a14c-5e4e-47a3-a198-808f207980c4n%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/20c0a14c-5e4e-47a3-a198-808f207980c4n%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/7ae6ae45-c341-4998-9229-74b133ac213fn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/7ae6ae45-c341-4998-9229-74b133ac213fn%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/CAEkBMfGRjuM10FWoCK0r4utbfaA6VBBSn_VOFgZuXBCB1qdqEg%40mail.gmail.com.