Skip to content
GitLab
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 5,262
    • Issues 5,262
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 569
    • Merge requests 569
  • 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 CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #22468
Closed
Open
Issue created Nov 15, 2022 by Ben Gamari@bgamari🐢Maintainer

Thread-safety of IORef is dangerously ambiguous

Currently the documentation of Data.IORef is quite ambiguous regarding the safety of using IORefs in multi-threaded programs. In particular, we provide atomicModifyIORef and friends, which are safe to use in a multi-threaded program. However, we do not provide atomicReadIORef (although technically atomicModifyIORef can be used to implement it albeit inefficiently). Consequently users are tempted to use readIORef despite the fact that this is unsafe (as these operations lack the necessary barriers to guarantee consistent memory ordering). Given that GHC itself contains such incorrect uses (e.g. in GHC.Utils.TmpFs) I think we should do something to hide this foot-gun.

I can see two options:

  • Introduce atomicReadIORef operations and clearly mark the non-atomic operations as unsafe for concurrent access
  • Give readIORef the necessary barriers. We could in principle continue to use the non-barrier'd operations in STRef.
Edited Nov 15, 2022 by Ben Gamari
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking