4 ms·
If deadlocks are so easy to fix why do they happen so often? Seriously, how many applications have you seen hang in your life? (not to discount the role of othe
by acconsta 11y ago
If deadlocks are so easy to fix why do they happen so often? Seriously, how many applications have you seen hang in your life? (not to discount the role of other race conditions in causing hangs, which the borrow checker also can't categorically prevent).
- GFK_of_xmaspast 11y agoNull pointer derefs are easy to find and fix and : yet.
- neandrake 11y agoThis is not always the case. Null pointer derefs are just indicators that the program got into an invalid state. Is the fix to provide some alternative pathway when the program got in a bad state or is it to prevent the bad state from happening in the first place? If the fix is to prevent the bad state, tracking down how that state occurred in the first place can often be time consuming in the case of data races.
- neandrake 11y agoI believe the comment reads that deadlocks are the "easiest concurrency problem" to debug -- but your question is moreso headed to the point that they are easy to introduce in a system. From the example, from a deadlock the locked threads and their stacktraces can be determined, which will help in pointing towards where the cause of the problem is. Compared to situations where the problem occurs due to a data-race causing an unexpected/invalid state but a problem doesn't manifest until later. Fixing this type of problem is more problematic as usually any exception/stacktrace that might crop up does not relate any information as to how the state became invalid in the first place. I tend to see these types of bugs more than deadlocks and in my experience they're always more involved in debugging compared to deadlocks.