axel, it's difficult to try to explain in words how a select behaves. On
that we can agree. For me, select cases can be channels, timeouts, external
events etc. If a task is in a select (none triggered yet) and there is an
interrupt that detects the select entry, it's ticked as triggered, the
select is torn down, and in time the select will be taken with that event
only. Not like Linux select which can deliver several causes. But if the
timrout came just before the pin, then.. etc. Temporal logic in this case
certainly makes sense.
torsdag 29. april 2021 kl. 15:28:03 UTC+2 skrev axel.wa...@googlemail.com:
> My argument is that you can't distinguish the case "neither was ready and
> highPriority and lowPriority became ready simultaneously and lowPriority
> was selected" from "highPriority became ready after lowPriority" (as long
> as there is the same code in both highPriority cases). Because there is no
> "simultaneous" or "after" in concurrency, unless you use synchronization -
> the real phrasing is "highPriority and lowPriority became ready
> simultaneously" and if, *in real time* that means one or the other came
> first is indeterminate. There is no implementation or scheduling argument
> here - this argument is purely based on the Go memory model and the spec.
>
> If there is no observable difference in behavior, the two are equivalent.
>
> But either way, as I said, it's not really the same, just based on
> readability and clarity. It's semantically equivalent, but semantically, Go
> is equivalent to Assembly and yet we prefer Go :)
>
> On Thu, Apr 29, 2021 at 3:11 PM Øyvind Teig <oyvin...@teigfam.net> 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
>> :
>>
>>> 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:
>>>>
>>>> 1. 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)
>>>> 2. However, if highPri has become ready between the first and the
>>>> second, then it would be taken (provided lowPri is not also ready)
>>>> 3. 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.
>>
> 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/d4e67a26-7478-4756-8409-dd74492493e3n%40googlegroups.com.
