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:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  7.10.3
      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):

 Alright, I think I have a theory for how we end up getting multiple
 entries despite having no thunk allocation inside `fromListWith`:

 1. Thread A enters a `fromListWith` closure and begins folding over the
 insertions
 2. At some point during this fold we need to garbage collect; the garbage
 collector constructs an `AP_STACK` closure capturing the state of Thread
 A, including the partially-finished `fromListWith` computation
 3. Garbage collection commences and finishes, evaluation resumes
 4. At some point Thread A is resumed, picking up the previously suspended
 `fromListWith` computation; we are blackholing lazily so no update to the
 closure is made
 5. At some later Thread B tries to force the same `fromListWith`
 computation; finding that it's not blackholed it enters
 6. We now have two mutator threads performing evaluation on the same,
 effectful computation with shared, mutable state.

 Does this sound plausible?

 The only bit that I'm a bit hazy on is point (5). That is, how is it that
 Thread B is able to enter the suspended computation given that (if I
 understand correctly) Thread A won't update the original `fromListWith`
 until finishes its evaluation and pops its associated update frame.

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