I will give you the pseudo code:
{ // step #1 do select on both
select high
select low
}
if high read:
return high
else:
// we read a low so do a high poll
{
select high:
default:
}
if high read:
enqueue low and return high
else:
if queue empty:
return low
else:
use queue and enqueue low from step #1 // FIFO order on low reads
The above code will always return high values over low values (if high
available), and return low values in order of events
> On Apr 29, 2021, at 8:29 AM, Øyvind Teig <oyvind.t...@teigfam.net> wrote:
>
> I sent that to the wrong entry! Is it possible that you could make a code
> example?
>
> torsdag 29. april 2021 kl. 15:20:40 UTC+2 skrev ren...@ix.netcom.com:
> It is trivial to do a priority select. Check the high priority channel again
> after getting a low priority value. If the high priority is available enqueue
> the low value and handle the high.
>
> It is also trivial to “delay” the handling to allow more time for high events
> to arrive if dealing with synchronized events and you need to account for
> jitter.
>
>> On Apr 29, 2021, at 8:10 AM, Øyvind Teig <oyvin...@teigfam.net
>> <applewebdata://42805515-6927-441B-BBB9-01033DA3AB17>> wrote:
>>
>> I agree with you.
>
>>
>> However, with the first select in the example we have a "first" and with the
>> second we have an "after" which might be considered race condition(s9 for
>> the purpose of seeing the example of what I was after.
>>
>> Also, scheduling arguments cannot be used here: like "we know that there is
>> no scheduling (of go goroutines) between the first and the second select."
>> If we know, it's not an argument.
>>
>> torsdag 29. april 2021 kl. 14:35:31 UTC+2 skrev axel.wa...@googlemail.com
>> <applewebdata://42805515-6927-441B-BBB9-01033DA3AB17>:
>> On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig <oyvin...@teigfam.net <>> wrote:
>> Interesting!
>>
>> 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
>>
>> One thing to point out is that since we are talking about concurrency, where
>> you can really only talk about something happening "after" something else
>> happened, if there is a causal edge between them, this really *is*
>> equivalent to a simple priority select. You can't observe the difference,
>> unless you add more synchronization - in which case we aren't really talking
>> about the code under discussion anymore.
>>
>> I fail to see that this is the general pri select that I am quering about
>> whether it has "appeared" in go over the last years.
>>
>> I tend to agree with you on this though. So to answer that question plainly:
>> No, there is no prioritized select in Go and I find it personally unlikely
>> that we'll get one. It might be possible to address some use cases when we
>> get generics, though.
>>
>> I have a stomach feeling that it can not be implemented by polling. In the
>> semantics of a select the whole select is evaluated before it is entered to
>> se if there is/are any guard(s) ready. If not, pick randomly. If not, set
>> alle guards up in some wait state.
>>
>> The default case I have always used like "since no event ready (polling)
>> then do something else than listening again on the same events". occam has
>> deafult (although it's called TRUE & SKIP), xC does not.
>> torsdag 29. april 2021 kl. 11:36:45 UTC+2 skrev Jan Mercl:
>> On Thu, Apr 29, 2021 at 11:24 AM Øyvind Teig <oyvin...@teigfam.net <>>
>> wrote:
>>
>> > This is not solved with a default clause, which transforms the selective
>> > choice waiting for some event to happen into busy polling. It's nice yo
>> > have some times, but that is something orthogonal to pri/ordered.
>>
>> Not sure if I would call it busy polling, but I meant schematically this:
>>
>> select {
>> case x := <-highPriority:
>> handle(x)
>> default:
>> select {
>> case x := <-highPriority:
>> handle(x)
>> case x := <-lowPriority:
>> handle(x)
>> }
>> }
>>
>> --
>> 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/47051a51-f040-4b51-a792-24a0f96c50f4n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/47051a51-f040-4b51-a792-24a0f96c50f4n%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...@googlegroups.com
>> <applewebdata://42805515-6927-441B-BBB9-01033DA3AB17>.
>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/cf43611c-599f-46d9-98ac-60ede00daea9n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/cf43611c-599f-46d9-98ac-60ede00daea9n%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
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ac6eecc4-ee82-4a21-9001-b2c704e74e8cn%40googlegroups.com
>
> <https://groups.google.com/d/msgid/golang-nuts/ac6eecc4-ee82-4a21-9001-b2c704e74e8cn%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/1E17A7D5-60C7-4D18-A61B-794AABC9F1FB%40ix.netcom.com.
