#11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Yuras): Replying to [comment:1 simonpj]:
This looks bad. Do you have a more detailed theory? Our thinking about lazy blackholing is that if two threads start to evaluate the same thunk, they may waste work but shoudl still get the same value. But that is not happening here and I'd like to understand why.
Reeveluating a thunk gives the same result only for pure computation, it is clearly not the case for (lazy) `ST`. In this particular case, the thunk captures mutable variables, and we have a race condition when two threads access them. The result depends on ordering. Also, I don't think `-feager-blackholing` actually fixes the issue. AFAIK it doesn't introduce a write barrier then replacing a thunk with a hole, so the race is still possible (though is harder to reproduce). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11760#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler