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?
On Thu, 29 Apr 2021, 15:44 'Axel Wagner' via golang-nuts, < golang-nuts@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.wagner...@googlemail.com> > wrote: > >> On Thu, Apr 29, 2021 at 3:54 PM Øyvind Teig <oyvind.t...@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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAJhgachVuBduF_ucmywVKfDM4On05ekNEgxGPmHgWm0V6xFDxw%40mail.gmail.com.
