[GHC] #9539: TQueue can lead to thread starvation

[GHC]

#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]:
 > 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
 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