Thanks, rog. I appreciate this! Even if I cant' stop thinking that a "pri" would have been sligtly more elegant. But you shall be praised for the try! I wont' take the time to fine read the code, though...
..Aside: Being more than busy to digest the fact that XMOS has announced a paradigm shift with keeping the xC compiler, but for new projects wanting us to code "in C" instead, with a library lib_xcore. There are reasons. But ordered select is kept! See my reaction blog note C plus lib_xcore black-boxes xC <https://www.teigfam.net/oyvind/home/technology/221-c-plus-lib_xcore-black-boxes-xc/> (disclaimer: no association with XMOS, no ads, no income, no gifts etc with my blogs. Only fun an expensens) torsdag 13. mai 2021 kl. 04:48:31 UTC+2 skrev ren...@ix.netcom.com: > 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 <oyvin...@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...@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/091bd9e7-a33e-4833-a33c-6ed3f5976861n%40googlegroups.com.
