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.
