#9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Replying to [comment:12 dfeuer]:
I'm 90% confident this is not actually fixed. We now get good results from `atomically $ do {...; readTQueue q}`. Unfortunately, I believe the exact same problem will still occur as soon as we go a little further, with `atomically $ do {... ; !x <- readTQueue q; return x}`. I believe the only true solution is to base `TQueue` on a real-time queue rather than an amortized one.
The original fix is straightforward, maybe we should add some documents to stop people explicit forcing the list reverse during transaction? The point is that after transaction finished, forcing thunk will only bring contention on blackhole, which will not stop consumer from making progress, thus solving the original issue perfectly. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9539#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler