torsdag 6. mai 2021 kl. 16:18:18 UTC+2 skrev axel.wa...@googlemail.com: > On Thu, May 6, 2021 at 4:06 PM Øyvind Teig <oyvin...@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. >
Since it looks like this is a thread with "us talking with each other" and not "me discussing with you" I will try to comment in line for all where it would be applicable, in the view that it's you who know what Go does. 16 new messages since I was here last time! (I only handle this at intervals, so that I can get some time with other things as well!-) But this one certainly needs a comment! No need to apologise! But I starting to get tired of myself hammering that I did not understand how *select-hi-default-select-hi-low* could possible work the way it was presented to work. I am indeed excited to read the next 16 messages, to see if that (now double) doubt still holds. But you made my day, Axel, I must admit 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. > Very interesting reading! Øyvind Ø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...@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/b000ae9c-4e64-4c21-b0df-d9e772332d2en%40googlegroups.com.
