@uchuukoukaishi · Post #368 · 07/31/2023, 01:36 PM
今天下午碰到一个并发问题，之前写的 Haskell 并发代码有考虑不周的地方，在特定情况下会死锁，简化一下是这样的： replicateM_ n_workers . forkIO $ do { -- Worker 线程 doSomethingThatMayFail; signalTSem semaphore; } -- 主线程 waitTSem semaphore 如果 doSomethingThatMayFail 抛异常导致线程挂了，那么 signal 就 unreachable，于是主线程会卡住。而 GHC 直接检测到了这个问题并在主线程（比较及时地）抛出了 BlockedIndefinitelyOnSTM 异常。 有点好奇是怎么实现的，于是读了一下 GHC，目前初步的理解是：Haskell 中的线程本身是一个会被 GC 的堆分配对象，当前线程 block 时这个线程会被放到 TVar 的 wait queue 里。如果 TVar 被 GC 了，那么这个线程本身也就 unreachable 了（线程本身并不是 GC root），会被 mark 掉。GC 过程中，如果发现某个 thread 是 unreachable 的，那么在最后关头会调用一个叫 resurrectThreads 的函数（Schedule.c），这个函数会检查线程状态对象的 "why_blocked" 字段，如果是 BlockedOnSTM（在 park 的时候设置的），那么就会在这个线程里抛出一个 BlockedIndefinitelyOnSTM 异常(相应地，其他 block 理由也会有其他种类的异常抛出)。 这个机制不使用任何 timer，并且一旦抛出异常就是真的发生 deadlock 了。缺点大概是不 complete ，比如用一个 StablePtr 维持住线程对象的命，就可以 hang forever 了。 #haskell
Hashtags