Robert :) > On May 15, 2021, at 3:48 AM, Øyvind Teig <oyvind.t...@teigfam.net> wrote: > > 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 (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 >> >> 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 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 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 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 - 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 (2012) >>> [3] Bell Labs and CSP Threads by Russ Cox >>> [4] Why build concurrency on the ideas of 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. >> > > -- > 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.
-- 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/BD1988D9-C75C-4B20-A9D8-708090B7F6E7%40ix.netcom.com.
