[GHC] #11760: runST with lazy blackholing breaks referential transparency

[GHC]

#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