On Thu, May 6, 2021 at 4:06 PM Øyvind Teig <oyvind.t...@teigfam.net> wrote:
> If that confirmation really is a confirmation, then the "Mercl code" is > still not a pri select that matches the pri select I was querying about. > I don't believe it is. It took a while to wrap my head around it - apologies for that. But yes, at this point I believe the specific property that is violated that you'd be interested in is as I said in my last message, the guarantee that "if the high-priority case becomes ready before (in the sense of the memory model) the low-priority case, then the high-priority case will be chosen". That's certainly a reasonable expectation to have from a priority select and it is not a guarantee that the code we gave you, using nested selects with defaults, provides. I believe we became hung up on the idea of what happens if the cases become ready *concurrently*. In that case, there is no real sensible answer to what any select implementation could guarantee. > Øyvind > > torsdag 6. mai 2021 kl. 14:29:31 UTC+2 skrev jesper.lou...@gmail.com: > >> On Wed, May 5, 2021 at 11:34 PM Bakul Shah <ba...@iitbombay.org> wrote: >> >>> >>> Imagine that the latency between the device detecting a disconnect >>> signal and a user hitting a disconnect button is D ns while the fire >>> detection latency is F ns. So if D > F the device would raise the >>> alarm even if you implement it all in hardware! The only difference >>> between a Go implementation vs a hardware one is the window size. >>> If you want to make it minimize it, Go is not the right solution. >>> For that, in H/W you'd probably *gate* the alarm line to the fire >>> department with the disconnect signal! But even so there is a small >>> window. >>> >>> >> There's a more contrived example which takes this argument to the >> extreme. It illustrates some of the problems. >> >> Imagine you had D on Venus, and F on Mars. You receive radio signals on >> Earth from F and D. Due to planet orbits, this system is in constant >> motion, so the window constantly changes. It makes it really hard to nail >> down a good window, though it can be argued we can precompute the position >> of planets and thus compensate. However, you might have other systems where >> even the prediction of the window size is impossible. >> >> Most computer systems, as Ian writes, exhibit the same window >> fluctuations at a far smaller scale, seemingly at random. In particular, >> time is not absolute in computer systems. See e.g., "There is no Now" ( >> https://queue.acm.org/detail.cfm?id=2745385) by Justin Sheehy for an >> example. The writing by Sheehy also injects an important point into these >> discussions: impossibility results. As you add more and more distribution >> to a system---of which one can argue that a modern multicore system is, in >> fact, a distributed system---you may end up with FLP or CAP in disguise. >> Both these results put a wooden stake through the determinism vampire. >> I don't think it is too far fetched to argue that prioritization, >> ordering and (non-)determinism are intertwined. >> >> >> -- >> J. >> > -- > 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/69b83b54-1094-4321-9c27-cf4131bf6393n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/69b83b54-1094-4321-9c27-cf4131bf6393n%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/CAEkBMfEnyiedLZ7kh1z1bR%2B5V0UbQyFc-4%2B26_Nwdei%2Bbp_tcA%40mail.gmail.com.
