‹ BackHN Continuity

Thread

Book review: Is parallel programming hard, and, if so, what can you do about it?

149 points · 66 comments · ahelwer

  1. hoistway · · focus · HN ↗
    Spent days tracking down a deadlock that only manifested under specific load. Definitely hard, even with good tooling.
    1. kccqzy · · 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. gpderetta · · focus · HN ↗
        Agree completely. But they become harder when you eschew standard constructs like threads and mutexes and bring-your-own losing nice things like debugger supports and stack traces. Now your logical tasks might be deadlocked, while your threads appear to be running correctly. This is surprisingly common this day with async runtimes and less than stellar debugging support.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.