Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • 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,932
    • Issues 4,932
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 464
    • Merge requests 464
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Merge requests
  • !337

WIP: rts: Ensure proper write ordering during indirection construction

  • Review changes

  • Download
  • Email patches
  • Plain diff
Closed Ben Gamari requested to merge wip/T15449 into master Feb 09, 2019
  • Overview 45
  • Commits 2
  • Pipelines 5
  • Changes 6

Previously (on architectures with weak memory models) there was a possibility that writes to an indirection's indirectee field would become visible before the writes that initialize the indirectee closure itself would become visible. We fix this by placing a write barrier between the closure construction and the write to indirectee:

#define updateWithIndirection(p1, p2, and_then) \
    prim_write_barrier;                                         \
    StgInd_indirectee(p1) = p2;                                 \
    #               <--- previously the write_barrier was here  \
    SET_INFO(p1, stg_BLACKHOLE_info);                           \

While this just moves an existing write barrier, there is a rather subtle implication: it is principle possible for the writes to p1->info to become visible before those to p1->indirectee. However, this is okay since we know that this field was earlier set to the owning TSO or blocking queue. When the stg_BLACKHOLE entry code sees a blackhole whose indirectee is a TSO or blocking queue it will retry or block as appropriate.

Fixes #15449 (closed).

Todo

  • validate on ARMv8
Edited Feb 10, 2019 by Ben Gamari
Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: wip/T15449