torsdag 29. april 2021 kl. 23:52:05 UTC+2 skrev rog:
> On Thu, 29 Apr 2021, 20:05 Øyvind Teig, <oyvin...@teigfam.net> wrote:
>
>> 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.
>>
>
> To start with, if you've got N clients where N isn't known in advance,
> it's not possible to use Go's select statement directly because it doesn't
> provide support for reading from a slice.
> You can do it with reflection though. It's not too hard to code something
> quite similar to your algorithm above.
> For example: https://go2goplay.golang.org/p/S_5WFkpqMP_H
>
Thanks! I like the fact that you can do it like this. However, there was
"client 2" in the log(?)
Øyvind
>
> I think the above code should fit your definition of fairness, and it
> seems to me that it's a reasonably general approach.
>
> cheers,
> rog.
>
> Ø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...@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
>>
>> <https://groups.google.com/d/msgid/golang-nuts/20c0a14c-5e4e-47a3-a198-808f207980c4n%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/d598dc96-08fa-4be2-9445-3147ded54c42n%40googlegroups.com.
