[GHC] #8345: A more efficient atomicModifyIORef'
GHC
ghc-devs at haskell.org
Sun Oct 5 20:44:45 UTC 2014
#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
More information about the ghc-tickets
mailing list