Here is a simple priority select implementation using unbuffered channels. https://play.golang.org/p/Hvl0iMr-cFW <https://play.golang.org/p/B5W-UjKxlq_5>
Uncomment the lines as instructed and you will see that channel A is always picked. What this demonstrates is that ‘priority’ and ‘event order’ is highly dependent on latency, event frequency, etc. The ’sleep’ + locks in this example function as an external clock - as long as all events are ready at the clock edge you can implement priority - but with async events and scheduling - priority is impossible. (In the absence of the sleep - the Go scheduler + OS scheduler determines whether A or B will run and scheduling delays will allow B events to arrive before an A event. You can also trivially change this example to implement the ‘close A, close B’ scenario using a single Go routine and will see the desired ’never ends’ state is obtained. (btw - there are probably some deadlock scenarios - I didn’t spend a lot of time on this) > On May 12, 2021, at 11:53 AM, Øyvind Teig <oyvind.t...@teigfam.net> wrote: > > I am not certain whether you start with Java and end up with describing a > possible implementation for Go, or stay with Java. In any case Java is your > starting point. > > I guess, comparing any feature of any language, from the outside, then the > feature comparison lists turn up. But since you brought in Java..: > > Then I can just as well throw in the JCSP library's Alternative (=ALT, > =select) class [1]. And here is their description of the associated > Alternative type: > By invoking one of the following methods, a process may passively wait for > one or more of the guards associated with an Alternative object to become > ready. The methods differ in the way they choose which guard to select in the > case when two or more guards are ready: > > select > <https://www.cs.kent.ac.uk/projects/ofa/jcsp/jcsp-1.1-rc4/jcsp-doc/org/jcsp/lang/Alternative.html#select()> > waits for one or more of the guards to become ready. If more than one become > ready, it makes an arbitrary choice between them (and corresponds to the > occam ALT). > priSelect > <https://www.cs.kent.ac.uk/projects/ofa/jcsp/jcsp-1.1-rc4/jcsp-doc/org/jcsp/lang/Alternative.html#priSelect()> > also waits for one or more of the guards to become ready. However, if more > than one becomes ready, it chooses the first one listed (and corresponds to > the occam PRI ALT). Note: the use of priSelect between channel inputs and a > skip guard (at lowest priority) gives us a polling operation on the readiness > of those channels. > fairSelect > <https://www.cs.kent.ac.uk/projects/ofa/jcsp/jcsp-1.1-rc4/jcsp-doc/org/jcsp/lang/Alternative.html#fairSelect()> > also waits for one or more of the guards to become ready. If more than one > become ready, it prioritises its choice so that the guard it chose the last > time it was invoked has lowest priority this time. This corresponds to a > common occam idiom used for real-time applications. If fairSelect is used in > a loop, a ready guard has the guarantee that no other guard will be serviced > twice before it will be serviced. This enables an upper bound on service > times to be calculated and ensures that no ready guard can be indefinitely > starved. > In that world Go would look like this (provided perhaps, it also supported > list type select guards): > > select > pri select > fair select > > [1] JCSP Alternative class > <https://www.cs.kent.ac.uk/projects/ofa/jcsp/jcsp-1.1-rc4/jcsp-doc/org/jcsp/lang/Alternative.html> > - I am not certain how much JCSP has been used. It's "beautiful" (my words). > Observe that they didn't make any GoCSP library.. > > ========== > Aside: After the above discussion in this thread I found what I searched for, > before I started it: a thread from 2012 [2]. Some déjà vu experience! > > Is there any Go page with the rationale for having a single select type and > not the other select type(s)? Like [3] or [4]. If not, maybe a new paragraph > to [4]? > > Øyvind > > [2] Priority select in Go > <https://groups.google.com/g/golang-nuts/c/ChPxr_h8kUM> (2012) > [3] Bell Labs and CSP Threads <https://swtch.com/~rsc/thread/> by Russ Cox > [4] Why build concurrency on the ideas of CSP? > <https://golang.org/doc/faq#csp> > ========== > > onsdag 12. mai 2021 kl. 16:52:19 UTC+2 skrev Haddock: > In addition to htq and ltq you have a third queue into which you also insert > a token once one has been added to htq or ltp. The thread/goroutine that > serves htq, ltp, hq, lq is blocked by this additional queue. When it is > empty, htq and ltq are also empty. So when the goroutine is blocked it is > fine in this case. This sound like this could be it :-) > > Well, coming to think of it just using a sempahore here for the third queue > consumes less memory: Just a counter that blocks the thread/goroutine once it > has reached 0. > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/ceeff584-7108-455d-b825-1f3845971134n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/ceeff584-7108-455d-b825-1f3845971134n%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/4A805B24-0104-48EE-9BD7-E58B71A58B71%40ix.netcom.com.
