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. afdbcreid · 1790313218 · focus · HN ↗

         They are, if you can attach a debugger. If only one thread is stuck and in production... Not so much (but there are still much harder bugs).

         1. kccqzy · 1790341565 · focus · HN ↗

            Just drain the traffic (make the load balancer temporarily not send traffic to it) and attach a debugger. I hope your load balancer has that feature because health checking also needs it.

Unofficial Hacker News client; not affiliated with Y Combinator.