[GHC] #8345: A more efficient atomicModifyIORef'
GHC
ghc-devs at haskell.org
Mon Oct 6 07:12:42 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):
It looks like my fears were unjustified. If I run this:
{{{#!hs
silly = \current -> (True, True)
{-# INLINE flipper #-}
stupid = newIORef False >>= \r ->
let
flop = atomicModifyIORef' r silly
in forever flop
main = do
flippy <- forkIO stupid
mapM_ print [x | x <- [1..], x `rem` 10000000 == 0]
}}}
with just one thread, and try either of the above implementations, it
prints things just fine. I don't see any obvious signs of allocation
anywhere in the `stupid` thread, so I would speculate that maybe
`atomicModifyMutVar#` always gives the scheduler a go. This looks like a
real good catch by parcs.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8345#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list