Print logging is pretty good for concurrency IMO because it doesn't stop the program and because it gives you a narrative of what happened. If you have a time

Print logging is pretty good for concurrency IMO because it doesn't stop the program and because it gives you a narrative of what happened. If you have a time travel debugger then you can record concurrency issues without pausing the program then debug the whole history offline, so you get a similar benefit without having to choose what to log up front. E.g. use Microsoft's WinDbg time travel integration: https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/time-travel-debugging-overview https://learn.microsoft.com/en-us/windows-hardware/drivers/d... Or on Linux use rr (https://rr-project.org/ https://rr-project.org/) or Undo (https://undo.io https://undo.io - disclaimer: I work on this). These have the advantage that you only need to repro the bug once (just record it in a loop until the bug happens) then debug at your leisure. So even rare bugs are susceptible. rr and Undo also both have modes for provoking concurrency bugs (Chaos Mode from rr - https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mode.html https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mo..., Thread Fuzzing from Undo - https://undo.io/resources/thread-fuzzing-wild/ https://undo.io/resources/thread-fuzzing-wild/)