1. 13 Nov, 2008 2 commits
    • Simon Marlow's avatar
      Fix another subtle shutdown deadlock · dddfba38
      Simon Marlow authored
      The problem occurred when a thread tries to GC during shutdown.  In
      order to GC it has to acquire all the Capabilities in the system, but
      during shutdown, some of the Capabilities have already been closed and
      can never be acquired.
    • Simon Marlow's avatar
      Fix an extremely subtle deadlock bug on x86_64 · 6d316585
      Simon Marlow authored
      The recent_activity flag was an unsigned int, but we sometimes do a
      64-bit xchg() on it, which overwrites the next word in memory.  This
      happened to contain the sched_state flag, which is used to control the
      orderly shutdown of the system.  If the xchg() happened during
      shutdown, the scheduler would get confused and deadlock.  Don't you
      just love C?
  2. 06 Nov, 2008 2 commits
  3. 05 Nov, 2008 2 commits
  4. 24 Oct, 2008 1 commit
  5. 23 Oct, 2008 2 commits
    • Simon Marlow's avatar
      Fix a bug in the new scheduler · bd6fe3a3
      Simon Marlow authored
      If the current thread blocks, we should yield the Capability
      immediately, because the thread and hence possibly the current Task
      are now owned by someone else.  This worked in the old scheduler, but
      we moved where the yield happens in the new scheduler which broke it.
    • Simon Marlow's avatar
      add an assertion · a4326c0e
      Simon Marlow authored
  6. 22 Oct, 2008 1 commit
    • Simon Marlow's avatar
      Refactoring and reorganisation of the scheduler · 99df892c
      Simon Marlow authored
      Change the way we look for work in the scheduler.  Previously,
      checking to see whether there was anything to do was a
      non-side-effecting operation, but this has changed now that we do
      work-stealing.  This lead to a refactoring of the inner loop of the
      Also, lots of cleanup in the new work-stealing code, but no functional
      One new statistic is added to the +RTS -s output:
        SPARKS: 1430 (2 converted, 1427 pruned)
      lets you know something about the use of `par` in the program.
  7. 15 Sep, 2008 1 commit
    • berthold@mathematik.uni-marburg.de's avatar
      Work stealing for sparks · cf9650f2
      berthold@mathematik.uni-marburg.de authored
         Spark stealing support for PARALLEL_HASKELL and THREADED_RTS versions of the RTS.
        Spark pools are per capability, separately allocated and held in the Capability 
        structure. The implementation uses Double-Ended Queues (deque) and cas-protected 
        The write end of the queue (position bottom) can only be used with
        mutual exclusion, i.e. by exactly one caller at a time.
        Multiple readers can steal()/findSpark() from the read end
        (position top), and are synchronised without a lock, based on a cas
        of the top position. One reader wins, the others return NULL for a
        Work stealing is called when Capabilities find no other work (inside yieldCapability),
        and tries all capabilities 0..n-1 twice, unless a theft succeeds.
        Inside schedulePushWork, all considered cap.s (those which were idle and could 
        be grabbed) are woken up. Future versions should wake up capabilities immediately when 
        putting a new spark in the local pool, from newSpark().
      Patch has been re-recorded due to conflicting bugfixes in the sparks.c, also fixing a 
      (strange) conflict in the scheduler.
  8. 20 Oct, 2008 1 commit
    • Simon Marlow's avatar
      FIX (partially) #2703: bug in stack overflow handling when inside block · cd22cec9
      Simon Marlow authored
      As a result of a previous ticket (#767) we disabled the generation of
      StackOverflow exceptions when inside a Control.Exception.block, on the
      grounds that StackOverflow is like an asynchronous exception.  Instead
      we just increase the stack size.  However, the stack size calculation
      was wrong, and ended up not increasing the size of the stack, with the
      result that the runtime just kept re-allocating the stack and filling
      up memory.
  9. 08 Oct, 2008 1 commit
    • Simon Marlow's avatar
      Fix #2663: we had a hard-wired capabilities[0] · 8ec22a59
      Simon Marlow authored
      For some unknown reason in schedulePostRunThread() we were always
      passing capabilities[0] rather than the current Capability to
      throwToSingleThreaded().  This caused all kinds of weird failures and
      crashes in STM code when running on multiple processors.
  10. 19 Sep, 2008 1 commit
  11. 12 Sep, 2008 1 commit
  12. 11 Sep, 2008 1 commit
  13. 09 Sep, 2008 2 commits
    • Simon Marlow's avatar
      Fix warnings · 848dafe8
      Simon Marlow authored
    • Simon Marlow's avatar
      Fix race condition in wakeupThreadOnCapability() (#2574) · d572aed6
      Simon Marlow authored
      wakeupThreadOnCapbility() is used to signal another capability that
      there is a thread waiting to be added to its run queue.  It adds the
      thread to the (locked) wakeup queue on the remote capability.  In
      order to do this, it has to modify the TSO's link field, which has a
      write barrier.  The write barrier might put the TSO on the mutable
      list, and the bug was that it was using the mutable list of the
      *target* capability, which we do not have exclusive access to.  We
      should be using the current Capabilty's mutable list in this case.
  14. 19 Aug, 2008 1 commit
  15. 02 Sep, 2008 1 commit
    • berthold@mathematik.uni-marburg.de's avatar
      Scheduler code cleanup · 297b05a9
      berthold@mathematik.uni-marburg.de authored
      This patch removes old code from the Schedule.c file.
      I removed GRAN code for GranSim, a simulator for parallel Haskell execution with GpH model.
      This code is inactive since ghc-4.x. 
      Code for PARALLEL_HASKELL has been partially removed. The remaining code is valid, but can 
      refer to nonexisting functionality in other files.
  16. 21 Aug, 2008 1 commit
  17. 21 Jun, 2008 1 commit
  18. 28 Jul, 2008 1 commit
    • Simon Marlow's avatar
      Change the calling conventions for unboxed tuples slightly · 02620e7c
      Simon Marlow authored
      When returning an unboxed tuple with a single non-void component, we
      now use the same calling convention as for returning a value of the
      same type as that component.  This means that the return convention
      for IO now doesn't vary depending on the platform, which make some
      parts of the RTS simpler, and fixes a problem I was having with making
      the FFI work in unregisterised GHCi (the byte-code compiler makes
      some assumptions about calling conventions to keep things simple).
  19. 23 Jul, 2008 1 commit
  20. 15 Jul, 2008 1 commit
  21. 17 Jun, 2008 1 commit
  22. 09 Jun, 2008 1 commit
  23. 16 Apr, 2008 3 commits
  24. 28 Feb, 2008 1 commit
  25. 22 Nov, 2007 1 commit
  26. 30 Oct, 2007 1 commit
  27. 19 Feb, 2008 1 commit
  28. 03 Jan, 2008 1 commit
  29. 12 Oct, 2007 1 commit
  30. 09 Oct, 2007 1 commit
  31. 27 Sep, 2007 1 commit
  32. 14 Sep, 2007 1 commit
  33. 03 Sep, 2007 1 commit