I already gave you the solution to this. Trust me it works. I did HFT for 7+
years - the algo is well known.
> On Apr 29, 2021, at 2:05 PM, Øyvind Teig <oyvind.t...@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? 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.
>>>
>>> --
>>> 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.
>
> --
> 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.
--
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/698E4066-ACCF-40E0-9546-140DCD9C2C0D%40ix.netcom.com.
