[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