Re: [GHC] #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators

[GHC]

#13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators
-------------------------------------+-------------------------------------
        Reporter:  pacak             |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  8.2.1-rc2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 I've put this aside for now. The current state of things is,

  * My current theory is that a closure is being entered multiple times,
 resulting in repeated observable mutation. It's still not entirely clear
 precisely which closure is being entered multiple times, but the evidence
 before us is consistent with the multiple mutation hypothesis.
  * compiling `unordered-containers` with `-feager-blackholing` appears to
 resolve the issue, however I'm pretty certain that this is merely
 shrinking the race window, not eliminating it altogether.
  * adding a `noDuplicate#` (e.g. see https://github.com/bgamari/unordered-
 containers/commit/bf799b2a00da8c78ac78d818de8f1963c7ff87ad) at the
 beginning of `unsafeInsertWith` also resolves the issue, even with lazy
 blackholing enabled. However, this seems like a very large hammer to place
 in an inner loop like this.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13615#comment:26>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler