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/CAEkBMfHynmh9_RDSfEw3G8SXwfuABfdXrn_yVxmKifwz_cUTKA%40mail.gmail.com.
