3 ms·
> 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
by 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 agoHow in the world is generating a random number and branching and doubling the number of instructions "no performance loss"?
- tapirl 5y agoNow 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.