Thread debugging has the reputation of being one of the most arduous tasks for developers. I beg to differ. Asynchronous debugging is so much worse. It’s supposed to solve threading problems, and to some degree, async helps… But it doesn’t make debugging simpler. I will get into that in the next post.
Today we’ll discuss the process of debugging threading issues and dealing with deadlocks and race conditions in the debugger.
For everyone having done multithreading and async programming, it’s fairly obvious that the amount of complexity required to (correctly) implement threading and async increases the cognitive requirements to understand the codebase to sometimes unfathomable amounts. Typically, this results in difficult to track down bugs, and over time what we often refer to as « spaghetti code » or « the big ball of mud ». To put this into context, I’d like to put forth a statement in regards to this.
Everyone who (falsely) believes they understand threading and async, don’t understand threading and async!
