#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 I've 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 `TSem`, and that `TSem` continues to be signaled, then the thread will eventually proceed. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15193#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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

#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: | -------------------------------------+------------------------------------- Comment (by simonmar): "first in" has a perfectly reasonable meaning: the execution of the program corresponds to some unspecified interleaving that sequentialises the operations, and you can define first-in using that ordering. Yes you can construct programs where the ordering is non-deterministic, but you can also construct programs where the ordering is deterministic, and in those cases the FIFO ordering property is useful to the programmer. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15193#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler