torsdag 29. april 2021 kl. 20:22:32 UTC+2 skrev rog:
> I agree with Axel's take here. It seems, Øyvind, that you are concerned
> more with principle than practice here. Can you give an example of a real
> world case where you think that this might actually matter?
>
Thanks, yes. I have written some about that in the *Nondeterminsim* blog
note, referred to at the top. I admit I indicated that seeing some code
might be interesting, but it was the principle I was after. In the end a
"yes" or "no".
Some from the chapter "*-Nondeterministic selective choice in
implementations is not good*": (Preceeding the quote I have been telling
about CSP's *external* nondeterministic choice in the *specfications*
("implement this any way you want") but in the *implementation* part we
have to take decisions (deterministic, inner choice: "we do it *this*
way"). I was thinking this is relevant because Why build concurrency on the
ideas of CSP? <https://golang.org/doc/faq#csp> Here's the quote:
*"The statement was that with the non-deterministic guarded choice in Go,
what happens is up to the run-time, which is “not good”. This
is implementation, not specification. With occam there is ALT or PRI ALT,
always coded as PRI ALT. For a server to be “fair” I have to code it
myself, it’s up to me, at the application level to find the best algorithm.
Which, during my years as occam programmer was “new starting channel index
in the ALT-set is the channel index of the served channel + 1
modulo-divided by number of channels”. Channels are clients[0..4]
(five) ALT‘ed in set [4,0,1,2,3] served index 4, then 4+1 rem 5 == 0 yields
next ALT set [0,1,2,3,4]. Just served 4 and you’re at the back of the set."*
The example here is a server with N clients where it is essential that none
of clients will starve and none jam the server. I have needed to do this
coding several times. Go has random select which in theory may mean
starving and jamming. I worked with safety critical fire detection, and it
was necessary to ensure this. Or at least we didn't dare to take the
chance. We could not just add another machine.
To use select when that's fair enough (pun 1) - "fair enough" (pun 2). But
If I want to be certain of no starving or jamming I need to code the
fairness algorithm. I can then promise a client that may have been ready
but wasn't served to come in before I take the previous clients that were
allowed. This is at best very difficult if all we have is select. Having
pri select as the starting point is, in this case, easier.
Øyvind
>
> On Thu, 29 Apr 2021, 15:44 'Axel Wagner' via golang-nuts, <
> golan...@googlegroups.com> wrote:
>
>> FWIW, maybe this helps:
>>
>> Assume a read happened from lowPriority, even though highPriority was
>> ready to read as well. That's, AIUI, the outcome you are concerned about.
>>
>> In that situation, how would you know that highPriority was ready to read
>> as well?
>>
>> On Thu, Apr 29, 2021 at 4:39 PM Axel Wagner <axel.wa...@googlemail.com>
>> wrote:
>>
>>> On Thu, Apr 29, 2021 at 3:54 PM Øyvind Teig <oyvin...@teigfam.net>
>>> wrote:
>>>
>>>> They could still both have become ready (not in the same "cycle")
>>>> between the two selects. Even if that probability is low, it would need
>>>> knowledge like yours to show that this may in fact be zero. There could be
>>>> a descheduling in between, one of those in my opinion, not relevant
>>>> arguments.
>>>
>>>
>>> FTR, again: Yes, it's definitely possible, but it's irrelevant. It makes
>>> no observable difference. Even if we had a prioritized select, it would
>>> still be *de facto* implemented as a multi-step process and even then, you
>>> might run into exactly the same situation - you could have both channels
>>> becoming ready while the runtime does setup, or you could have a random
>>> scheduling event delaying one of the goroutines infinitesimally, or you
>>> could have…
>>>
>>> This is why we *don't* talk about the behavior of concurrent programs in
>>> terms of cycles and time, but instead based on causal order. We don't know
>>> how long it takes to park or unpark a goroutine, so all we can say is that
>>> a read from a channel happens after the corresponding write. In terms of
>>> time, between entering the `select` statement and between parking the
>>> goroutine might lie a nanosecond, or a million years - we don't know, so we
>>> don't talk about it.
>>>
>>> The memory model is exactly there to abstract away these differences and
>>> to not get caught up in scheduling and cycle discussions - so, FWIW, if
>>> these arguments are not relevant, you shouldn't bring them up. Logically,
>>> between the first `select` statement and the second `select` statement,
>>> there is zero time happening. Arguing that there is, is using exactly those
>>> irrelevant arguments about schedulers and processing time.
>>>
>>>
>>>> torsdag 29. april 2021 kl. 15:47:42 UTC+2 skrev Jan Mercl:
>>>>
>>>>> On Thu, Apr 29, 2021 at 3:23 PM Øyvind Teig <oyvin...@teigfam.net>
>>>>> wrote:
>>>>>
>>>>> > 4c is not "correct" as I want it. In the pri select case, if more
>>>>> than one is ready, then they shall not be randomly chosen. Never. They
>>>>> should be selected according to priority.
>>>>>
>>>>> That's not what 4c says. Instead of "more than one ready" it says
>>>>> "both high and low _get ready at the same time_".
>>>>>
>>>>> Note that in the first approximation the probability of 4c happening
>>>>> is approaching zero. If we consider time "ticks" in discrete quanta,
>>>>> the probability is proportional to the size of the quantum. And
>>>>> depending on a particular implementation of the scheduler the
>>>>> probability of 4c can still be exactly zero. For example, the OS
>>>>> kernel may deliver only one signal at a time to the process etc.
>>>>>
>>>>> So the "Never" case may quite well never happen at all.
>>>>>
>>>> --
>>>> 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/2460a16f-af1b-4613-ba4a-72b13e816a2bn%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/golang-nuts/2460a16f-af1b-4613-ba4a-72b13e816a2bn%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/CAEkBMfFC1gtxbWZsy88gM4ymPncCjs6Q3YJpTcXym8bT1Ev6Kw%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFC1gtxbWZsy88gM4ymPncCjs6Q3YJpTcXym8bT1Ev6Kw%40mail.gmail.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/20c0a14c-5e4e-47a3-a198-808f207980c4n%40googlegroups.com.
