Thanks for your comments. I'll try to respond to several here. They also all apply! (Even if I see while I write that two more have arrived.)
This thread seems to have taken me to places where I didn't intend to go. Go is no language for this kind of application, not even with a pri select. I know that. Just see how they removed rendezvous from Ada for these type of applications, for the Ravenscar profile: https://en.wikipedia.org/wiki/Ravenscar_profile "No_Select_Statements"! (I also have a blog note about this). Just the fact that a language uses a queue for the select is a problem by itself. They are not deterministic and thus any select based on them cannot be hard real-time and safety critical. (That being said both soft real-time and queues are approved in many safety critical applications. It depends on how that usage is reasoned about.) My interest here is purely academical. Then, when I queried about pri select in go and the Jan Mercl's post on the almost top here set up the "select hi, default hi low", I got stuck in a way. I am *still* there. It has been said above that select is not atomic (not one window), and my query is what happens between the window of the first select and the window of the second select in that code. And what happens inside those windows. I have tried to guess in previous comments, and I thought there was a confirmation. 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. Ø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.
