Yes, it doesn't explicitly state the rate or distribution of events. But it is a good reminder of what happens when your whatevers/second are pretty high - see the famous "One in a million is next Tuesday" [1]. "Rare" is soon if you roll the dice fast enough.
Any time your service has a high TPS, your API gets a lot of calls, a button in your app gets pressed a lot, ... this applies.
Critically, "a lot" is defined relative to your failure tolerance. It may actually be very fast or a lot, or not particularly fast but it really really needs to work.
It highlights the fallacy of equating "low probability" and "won't happen".
> "Rare" is soon if you roll the dice fast enough.
Indeed. One fun example is LHC[1], where the probability of a proton in a single bunch hitting a proton in the bunch going the opposite direction is on the order of 10^-21, yet due to huge number of protons per bunch and large number of bunches per second, it still results in ~10^9 collisions per second.
> And I’ve seen some absolute doozies in my time – race conditions on MP machines where a non interlocked increment occurred (one variant of Michael Grier’s “i = i + 1” bug)
I could not find any info about that bug, anyone got a link or a source?
I assume that bug is referring to the fact that while i = i + 1 may look atomic to you as a human, in the computer it turns into
Read i into register.
Add one to that register.
Write i back to the memory location.
And there's a window during that "add one to the register" where you can obviously have something jump in and write something else to that memory location.
What happens on your real processor is more complicated since this is going to relate to cache coherency between the processors, not directly writing RAM at that point, and that's a deep rabbit hole. I couldn't describe it all in detail anyhow. But I can observe it doesn't take much at all to turn that one cycle vulnerability into something with a larger target.
Any time your service has a high TPS, your API gets a lot of calls, a button in your app gets pressed a lot, ... this applies.
Critically, "a lot" is defined relative to your failure tolerance. It may actually be very fast or a lot, or not particularly fast but it really really needs to work.
It highlights the fallacy of equating "low probability" and "won't happen".
[1] https://docs.microsoft.com/en-us/archive/blogs/larryosterman...