#15193: QSem makes nonsense claim -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description:
It says waiting threads are serviced in FIFO order. This isn't really a meaningful statement. What does "first in" mean? Furthermore, the first step in `waitQSem` is `takeMVar`, which provides no ordering guarantees whatsoever. As far as I can tell, there's no meaningful difference between a thread waiting a long time in the queue and one waiting a long time to get into the queue. So I think we probably want to weaken the promise here to match the `MVar` fairness guarantee: if a thread waits on a `TSem`, and that `TSem` continues to be signaled, then the thread will eventually proceed.
New description: It says waiting threads are serviced in FIFO order. This isn't really a meaningful statement. What does "first in" mean? Furthermore, the first step in `waitQSem` is `takeMVar`, which provides no ordering guarantees whatsoever. As far as I can tell, there's no meaningful difference between a thread waiting a long time in the queue and one waiting a long time to get into the queue. So I think we probably want to weaken the promise here to match the `MVar` fairness guarantee: if a thread waits on a `QSem`, and that `QSem` continues to be signaled, then the thread will eventually proceed. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15193#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler