[GHC] #15626: Optimise wakeups for STM
#15626: Optimise wakeups for STM -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4961 | Wiki Page: -------------------------------------+------------------------------------- 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). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15626 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
participants (1)
-
GHC