> We would have to consider all possible combinations of code paths and timings, and we cannot hope to write tests that cover all combinations. Not to take awa

> We would have to consider all possible combinations of code paths and timings, and we cannot hope to write tests that cover all combinations. Not to take away from this fantastic article, but I've felt for a while that this particular point is bullshit. Surely it's possible to write tools that do, indeed, test all possible code paths. I'm not up on the literature, but don't there exist proofs for unsynchronized lockless algorithms in certain specific cases? If so, it would be interesting to think about how this could be generalized.. I imagine that much of the literature on atomic transactions must touch on this kind of stuff, no to mention networking protocols that may receive messages out of order or deal with unpredictable timing, etc. There should be tools that we automatically reach for, like gdb, as soon as we introduce threading and need to check if we did it reliably. Moreover, such tools should help you find problems that may not occur on your system, but might be theoretically a problem on other systems, just like compiler warnings that warn of dependencies on pointer size.