#8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:10 carter]:
Reason being that the definition of atomicModify does a CAS retry loop internally. (though maybe yielding to the scheduler could be a good thing! )
If it's CAS, then yeah, it's probably reasonably safe to avoid the heap check, since CAS can't be interrupted by anything else on the same OS thread. The only exception is if a program (knowingly or unknowingly) uses `atomicModifyIORef'` to allow a thread switch. But I want to emphasize that I don't know enough about these inner workings to know if this change could actually cause this sort of problem. I just raised the issue so better-informed people like you can come up with a good answer. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8345#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler