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
#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]: 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