[GHC] #15193: QSem makes nonsense claim

GHC ghc-devs at haskell.org
Mon May 28 21:36:05 UTC 2018


#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


More information about the ghc-tickets mailing list