[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