Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,244
    • Issues 5,244
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 568
    • Merge requests 568
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #228
Closed
Open
Issue created Jun 15, 2004 by Simon Marlow@simonmarDeveloper

DiffArray deadlock

Posted to libraries@haskell.org, by Lauri Alanko
[la@iki.fi]:

The following program gets stuck in ghci, and when
compiled with ghc and
run, fails with "Fail: thread blocked indefinitely".

import Data.Array.Diff
main = print (a // [((a ! 0, 1))] ! 0)
    where a = array (0,0) [(0,0)] :: DiffArray Int Int

When DiffArray is replaced with Array, it just prints
out "1" as it
should.

Apparently there is some kind of a deadlock internally,
with the update
operation holding the lock already before the lookup
operation is
evaluated.

I think the solution is to evaluate all the indices in
the argument to
replaceDiffArray _before_ obtaining the lock. Changing
a single line in
Diff.hs gives a partial quick fix:

@@ -287 +287 @@
-a `replaceDiffArray` ies = do
+a `replaceDiffArray` ies = sum (map fst ies) `seq` do

However, in DiffUArray, when the underlying imperative
array is unboxed,
the operation is strict also in the elements, and then
(and _only_ then)
the elements, too, need to be evaluated before the MVar
is taken, or
otherwise their evaluation may lead to a deadlock.

I'm not really sure what would be the neatest solution.


Lauri Alanko
la@iki.fi
Trac metadata
Trac field Value
Version 6.2.1
Type Bug
TypeOfFailure OtherFailure
Priority low
Resolution ResolvedFixed
Component libraries/base
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking