7 ms·

> but (deterministic-select cases) hey are peculiar. It looks for most select blocks in Go code, it doesn't matter whether or not they are non-deterministic or

• lanstin 5y ago
  Any time there is more than one channel being selected for it needs to cover them all equally.
  • tapirl 5y ago
    Equality is meaningful only if at least two case operations are always non-blocking. This is rare in practice. In fact, in practice, sometimes, I do hope one specified case has a higher priority than others if they are all non-blocking.
    • lanstin 5y ago
      Wouldn't it be the case id one worker was pulling work asynchronously delivered from two places? I only use one go routine / one channel myself, but the name select itself very strongly implies it is a yield type operation where any of a number of async actions can wake it for their callback to run. Albeit without a callback syntax, it is async and better be fair.
    • lanstin 5y ago
      As far as priority goes, most interesting cases will have priority based on the data in the read, except for this specific case of a done chan el and a data channel. I used that pattern at first but have been moving away from it. To be sure i am mostly writing long lived processes with fixed pools of worker go routines and either never exit or exit based on WaitGroups determining the work is all done.
      • tapirl 5y ago
        Yes, it (the lack of deterministic-select) is only annoying for several special cases. For most cases, it doesn't matter whether or not the default behavior is deterministic.
• rplnt 5y ago
  > user code could simulate non-deterministic I'm curious how? > Not vice versa There are pretty common patterns for this. At least for real word cases where you might have one special channel that you always want to check. Ugly, but in relation to the previous question, I don't see how one is doable and one isn't?
  • tapirl 5y ago
    > > user code could simulate non-deterministic > I'm curious how? if rand.Intn(2) == 0 { select { case: <-chan2_whichItreatTheSameAsChan3 // a higher priority case: 0xFF ->chan3_whichItreatTheSameAsChan2 } } else { select { case: 0xFF ->chan3_whichItreatTheSameAsChan2 // a higher priority case: <-chan2_whichItreatTheSameAsChan3 } } Yes, it increases verbosity to the other way, but no performance loss.
    • morelisp 5y ago
      How in the world is generating a random number and branching and doubling the number of instructions "no performance loss"?
      • tapirl 5y ago
        Now the non-deterministic implementation does more work than a deterministic implementation. It generates a random number and sorts the branches. The latter (sorts the branches) is not needed in the above pseudo code. Doubling the number of instructions has no impact on run-time performance. And there are more optimization opportunities in implementing a deterministic design. Now, the non-deterministic implementation needs to lock all involved channels before subsequent handling, a deterministic implementation might not need to.
• usrbinbash 5y ago
  > Not vice versa (the current design). select { case: <-chan1_whichIWantToCheckFirst default: } select { case: <-chan2_whichItreatTheSameAsChan3 case: 0xFF ->chan3_whichItreatTheSameAsChan2 }
  • tapirl 5y ago
    Yes, as I have mentioned, there is performance loss, comparing to select { case: <-chan2_whichItreatTheSameAsChan3 // a higher priority case: 0xFF ->chan3_whichItreatTheSameAsChan2 }
    • usrbinbash 5y ago
      The real usecases where I need deterministic select, are so few that a small performance loss doesn't matter to me.
      • tapirl 5y ago
        Sometimes, it is not related to performance loss, it is related to implementation cleanness and complexity.
        • usrbinbash 5y ago
          A separate `select` with empty `default` is about as simple and clean as it gets. It is easy to read, easy to reason about, and, most importantly, conveys the intention of the code perfectly.
    • morelisp 5y ago
      1) Is there really a performance loss compared to if select was deterministic? 2) What in the world do you need such code for?
      • tapirl 5y ago
        1) surely. 2) just read: https://groups.google.com/g/golang-nuts/c/SXsgdpRK-mE/m/CT7UjJ3aBAAJ https://groups.google.com/g/golang-nuts/c/ZrVIhHCrR9o https://groups.google.com/g/golang-nuts/c/lEKehHH7kZY/m/SRmCtXDZAAAJ
• uluyol 5y ago
  Er, when it comes to concurrency, non-determinism is usually cheaper than determinism. As soon as you care about ordering, you almost always have to synchronize, and that has a cost. Austin Clements (of the Go runtime team) wrote a paper that explores this in detail [1]. That was before joining the Go team, but the concepts are universal. [1] https://people.csail.mit.edu/nickolai/papers/clements-sc.pdf https://people.csail.mit.edu/nickolai/papers/clements-sc.pdf