Thread

1. hoistway · 1790304362 · focus · HN ↗

   Spent days tracking down a deadlock that only manifested under specific load. Definitely hard, even with good tooling.

   1. kccqzy · 1790306254 · focus · HN ↗

      What kind of tooling were you using? IMO, deadlocks are some of the easiest concurrency bugs to diagnose. If you can see the thread stacks, it is easy to see threads are blocked from acquiring a lock. If you can attach a debugger, it is easy to see which locks are involved. Then you can pretty much figure things out using the straightforward guideline that if multiple locks are involved, they must be acquired in the same order in all code paths.

      I don't want to devalue your experience, but I am surprised to hear that. Livelock is harder to debug. Silent data corruption caused by missing or wrong synchronization is way harder to debug.

      1. stingraycharles · 1790313482 · focus · HN ↗

         > Silent data corruption caused by missing or wrong synchronization is way harder to debug.

         Reminds me of being a young and ambitious C++ programmer 25 years ago, discovering that when you have a map and do “return m[k]”, it is not, in fact, a read-only operation when k does not exist. After which I learned that const-correctness is not just a nice-to-have, especially in multithreaded applications.

         But yeah deadlocks are hardly ever a difficult issue to diagnose. They may potentially be difficult to resolve, but at that point, it very much suggests that there’s an architecture / design issue.

Unofficial Hacker News client; not affiliated with Y Combinator.