Jan, I agree on your list, it's better set up than mine. But you can add a point after (4.) though, call it (second.pre), dealing with what might have happened after the first select decided that none were taken until it evaluates the precondition to the second select.
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. As I discussed (and several with me) in the blog note, the fact that Go doesn't seem to have it, then go needs another definition of "fair" than what is normal discussing these things. The basic idea for Google was, if we have a problem with fairness (none gets starved, all get served), just add another computer (said over a beer). Plus, the need for the fairness that one can build with a pri select (most often by reordering the list of guards according to one's pleasing of what one might think of as fair), is according to Goodle (on go, I think), so tiny that we make it simple: drop it. Of course it's also easy to try to implement one's own fairness and fail with it. In a realtime system it's not that easy to test, and these things most often are best evaluated on paper. So a formal proof might do. torsdag 29. april 2021 kl. 14:58:23 UTC+2 skrev Jan Mercl: > On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig <oyvin...@teigfam.net> wrote: > > > Your suggestion would in fact do pri select in the special case 1. below: > > > > Poll highPri first (take it if it's ready), if highPri not ready then > take lowPri (provided highPri has not become ready since the first poll) > > However, if highPri has become ready between the first and the second, > then it would be taken (provided lowPri is not also ready) > > If both have become ready when the second select is entered they would > be taken 50% of the time on the average > > My analysis is different. There are four cases on entry of the outer > select statement: > > 1. high is ready and low is ready -> high handled, correct. > 2. high is ready and low is not ready -> high handled, correct. > 3. high is not ready and low is ready -> low handled, correct. > > The "interesting" case is > > 4. high not ready and low not ready. > > We enter the default clause of the outer select statement and enter > the inner select statement. Now there are three subcases when > eventually something gets ready: > > 4a. high gets ready before low gets ready -> high handled, correct. > 4b. low gets ready before high gets ready -> low handled, correct. > 4c. both high and low get ready at the same time -> one of them is > randomly chosen, correct. > -- 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/3d62317e-4831-47e5-84fe-a932518e48e6n%40googlegroups.com.
