[GHC] #15626: Optimise wakeups for STM

GHC ghc-devs at haskell.org
Tue Sep 11 12:08:19 UTC 2018


#15626: Optimise wakeups for STM
-------------------------------------+-------------------------------------
        Reporter:  osa1              |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.5
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D4961
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by osa1:

Old description:

> As discovered while debugging #15544, the previous attempt at optimising
> STM wakeups (Phab:D4961, merged as
> 502640c90c3d0fbb6c46257be14fdc7e3c694c6c) broke other things (see comment
> 17) and we're going to revert it. This is the tracking ticket for this
> issue.
>
> To summarize the problem: when a thread from capability 2 is in wait list
> of a TVar and we update the TVar in capability 1 we send a wakeup message
> to capability 2. If before capability 2 actually wake ups the thread
> capability 1 updates the TVar again we send a message again, causing
> redundant wakeup message sending. Ideally we should somehow mark the TSO
> as "awoken" and not send wakeup messages more than once. Phab:D4961 did
> exactly this, but in a wrong way (updated a field of TSO that shouldn't
> have been updated).

New description:

 As discovered while debugging #15544, the previous attempt at optimising
 STM wakeups (Phab:D4961, merged as
 502640c90c3d0fbb6c46257be14fdc7e3c694c6c) broke other things (see comment
 17) and reverted in Phab:D5144. This is the tracking ticket for this
 issue.

 To summarize the problem: when a thread from capability 2 is in wait list
 of a TVar and we update the TVar in capability 1 we send a wakeup message
 to capability 2. If before capability 2 actually wake ups the thread
 capability 1 updates the TVar again we send a message again, causing
 redundant wakeup message sending. Ideally we should somehow mark the TSO
 as "awoken" and not send wakeup messages more than once. Phab:D4961 did
 exactly this, but in a wrong way (updated a field of TSO that shouldn't
 have been updated).

--

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15626#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list