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 from 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
#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 dfeuer): Replying to [comment:21 winter]: progress, thus solving the original issue perfectly.
In fact, the basic requirement for using `TQueue` is that you should
have fast enough consumers, with this requirement met, as long as we give consumers chances to do the `reverse`, the list will not accumulate and each blackholing should be short. The original "fix" only works if 1. The value pulled from the queue isn't needed to finish the transaction, and 2. The thread only needs to pull one value from the queue. So it fixes the problem ''in its original context'', but not in any larger settings. Since the whole point of STM is to be "compositional", I don't think this can honestly be called a fix. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9539#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler