Changes between Version 2 and Version 3 of LightweightConcurrency


Ignore:
Timestamp:
May 4, 2012 10:04:15 PM (2 years ago)
Author:
kc
Comment:

More text

Legend:

Unmodified
Added
Removed
Modified
  • LightweightConcurrency

    v2 v3  
    11= Lightweight Concurrency in GHC = 
     2 
     3This page documents the effort to move GHC's concurrency support from its current location in the C part of the runtime system (RTS) to Haskell. This works builds on Peng Li's earlier work (http://community.haskell.org/~simonmar/papers/conc-substrate.pdf). This page contains information about the design, implementation, problems and potential solutions for building user-level concurrency primitives in GHC. 
    24 
    35== Introduction ==  
    46 
    5 GHC has a rich support for concurrency (forkIO, MVars, STM, Asynchronous exceptions, bound threads, safe FFI, transparent scaling on multicores, etc.) and a fast and robust runtime system. However, the concurrency support is implemented in C and baked into the RTS. The concurrency primitives interact among each other, and with the lightweight thread scheduler, non-trivially through a cascade of locks and condition variables.  
     7GHC has a rich support for concurrency (forkIO, MVars, STM, Asynchronous exceptions, bound threads, safe FFI, transparent scaling on multicores, etc.) and a fast and robust runtime system. However, the concurrency support is implemented in C and baked into the RTS. The concurrency primitives non-trivially interact among each other, and along with the lightweight thread scheduler, through a cascade of locks and condition variables. Often times, the invariants on which RTS fields can be accessed when are expressed as comments, and enforced through assertions [See source:rts/Task.h@085c7fe5d4ea6e7b59f944d46ecfeba3755a315b#L37 for one such fascinating example]. This policy of enforcing through assertions keeps the overheads low, but makes the task of modifying and extending the runtime cumbersome. 
     8 
     9But, why would we be interested in modifying GHC's concurrency environment? There are several good reasons to believe that a particular concurrent programming model, or a scheduling policy would not suit every application. With the emergence of many-core processors, we see NUMA effects becoming more prominent, and applications might benefit from NUMA aware scheduling and load balancing policies. Moreover, an application might have a better knowledge of the scheduling requirements -- a thread involved in user-interaction is expected to be give more priority over threads performing background processing. We might want to experiment with various work-stealing or work-sharing policies. More ambitiously, we might choose to build X10 style async-finish or Cilk style spawn-sync task parallel abstractions. Ideally, we would like allow the programmer to write an application that can  seamlessly combine all of these different programming abstractions.