Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,826
    • Issues 4,826
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 443
    • Merge requests 443
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #20947

Closed
Open
Created Jan 15, 2022 by Ben Gamari@bgamari🐢Maintainer

Drop the non-threaded scheduler's ad-hoc deadlock detection logic

Usually the RTS detects deadlocks via the garbage collector finding unreachable TSOs. For instance, a thread which is reachable only from, e.g., the blocking queue of an MVar# which itself is not reachable must be deadlocked.

However, the non-threaded RTS also has a second path (in scheduleDetectDeadlock) by which deadlocks can be identified: if we reach a state where the run queue is empty, even after a major GC (which might shake some threads lose due to, e.g., finalization) then the RTS considers the program deadlocked. Moreover, in the case of (a) the WinIO event manager, and (b) GHC RTS API users, this logic can cause false positives.

The WinIO case occurs when the program blocks on IO (which is achieved by blocking on an IOPort), at which point the RTS should block on an IO completion port; when the IO finishes, the process will be awoken and the RTS will fill the IOPort. However, the scheduler-based deadlock detection logic prevents this from happening, instead concluding that the process is deadlocked. WinIO currently attempts to work around this by introducing a new thread status, BlockedOnIoCompletion, which disables the scheduler-based check. However, as found in #18382, this is not a robust solution and can cause some true deadlocks to be overlooked.

As far as I can tell there are no deadlocks which the scheduler-based deadlock detection logic can catch that the non-threaded scheduler cannot. In light of this, I suggest that it be dropped.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking