On Sun, Nov 27, 2016 at 5:47 PM Michael Jones <michael.jo...@gmail.com> wrote:
> Wait… *“If any of these fails to produce a correct result…”* Really? I > believe that we want the correct result under any valid schedule, including > the most perverse, and that anything less means a failure of the design of > the underlying system. Perhaps I misunderstand what you imply. > > > Or perhaps I'm just bad at writing :) What I meant is what you wrote: we want to try random schedules (under the assumption that these random schedules are possible interleavings). The code must behave the same, observationally, under any of these schedules. In particular, pick any schedule and deem it the "deterministic one". If the code is correct, any schedule should behave as the "determinstic one" observationally. The problem is that most optimized schedulers have a "common schedule order" which they prefer. The other ways to schedule only shows up once the system is under stress or load. And the reason we get another schedule is often because some package in the system, totally unrelated to the code we are scrutinizing, executes in the same process, but in another goroutine. Thus, it pushes our code in ways which alters the schedule. Test cases, which isolate packages, are not going to find anything amiss. Also note that this has nothing to do with data races (which the race detector finds). Usually the reason your code breaks down has to do with some kind of causal dependency you didn't account for logically in your code. It then leads to collapse in a relative or temporal way[0]. Luckily, there are many situations in which your system doesn't really have the guarantees you think, but it will gracefully recover from the odd events anyhow. In practice, we can often get away with a weaker consistency than a linearizable consistency. And this is why many concurrent programs can run, even though there are some schedules in them which have never been tested or are slightly dubious from a correctness perspective. [0] The funniest example is when you have three planets, A, X, and B where X is in the middle between A and B. If a message is broadcast at exactly the same point in time from the planets, the arrival is different on the planets: A sees A, X, and then B B sees B, X and then A X sees X, and then A+B at the same time (any interleaving is possible if we force serialization) You may be tempted to write a protocol which assumes these orderings, but planets move, so you can't. You are forced to obey the laws of physics and they say information flow is relative. The same happens inside a CPU, though the window is measured in nanoseconds, not years. -- 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. For more options, visit https://groups.google.com/d/optout.
