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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ceeff584-7108-455d-b825-1f3845971134n%40googlegroups.com.
