6 ms·

Are you saying that concurrency issues can reliably be found via testing?

• pmarreck 7y ago
  Well, they can't be deterministically found since process scheduling is not deterministic (notable exception: Haskell, I believe, has a way to do deterministic concurrent scheduling!), but I have definitely seen fails that only crop up when the suite is run concurrently, and it usually turns out that the code failing in those circumstances has made assumptions about application state that do not hold true in a concurrent context
  • btilly 7y ago
    OK, intermittently your test suite fails nondeterministically 0.01% of the time. Do you imagine that this will be sufficient to find which of the last thousand commits introduced the bug? I would recommend using specialized tools for the task like Intel's Thread Inspector or Coverity's Helgrind.
    • pmarreck 7y ago
      Or one could simply try very hard not to mutate any state that is available to another process and corral all such code that requires doing so (which most of the time ends up being only a small portion of the code; the rest can be designed functionally, just passing values in and back out with no other side-effects) into a thin I/O layer, which is (I believe) the Hexagonal Architecture and is explained quite well by Gary Bernhardt here: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries
      • btilly 7y ago
        This is not an either or, it is an and. The one being a good idea doesn't preclude the other from being a good idea as well. Do them both. (And also avoid concurrency wherever you can. And of the available forms of concurrency, threads are one of the worse ones.)
        • pmarreck 7y ago
          Agree!