And I believe you are very wrong in that belief. However, a reliable statistic is not the first search result that I can find, so we’ll have to disregard the disagreement on that point.
You lost me at your C# multithreading reasoning though. A debugger will always interfere with the processes you are looking at, hence making debugging of multithreading-related errors a game of whack-a-mole.
A debugger will always interfere with the processes you are looking at, hence making debugging of multithreading-related errors a game of whack-a-mole.
It’s a very pleasant debugging experience when you can easily switch threads, have them log what happened first, check the variables in the thread at the moment in time it was hit (vs now), etc. etc.
And I believe you are very wrong in that belief. However, a reliable statistic is not the first search result that I can find, so we’ll have to disregard the disagreement on that point. You lost me at your C# multithreading reasoning though. A debugger will always interfere with the processes you are looking at, hence making debugging of multithreading-related errors a game of whack-a-mole.
It’s a very pleasant debugging experience when you can easily switch threads, have them log what happened first, check the variables in the thread at the moment in time it was hit (vs now), etc. etc.
Most concurrency problems disappear at the pace of a debugger.