Changes between Version 80 and Version 81 of LightweightConcurrency


Ignore:
Timestamp:
May 22, 2012 9:15:08 PM (3 years ago)
Author:
kc
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • LightweightConcurrency

    v80 v81  
    3535But, 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 given 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, with pluggable scheduling and load balancing policies.
    3636
    37 While we want to provide flexibility to the Haskell programmer, this should not come at a cost of added complexity and decreased performance. This idea reflects in the synchronization abstractions exposed to the programmer - [#PTM Primitive Transactional Memory(PTM)]), and our decision to keep certain pieces of the concurrency puzzle in the RTS ([#SafeForeignFunctionInterface Safe FFI],[#Thunksandblackholes Blackholes]). One would think lifting parts of the runtime system to Haskell, and retaining other parts in C, would complicate the interactions between the concurrency primitives and schedulers. We abstract the scheduler interface using PTM monads, which simplifies the interactions. The figure below captures the key design principles of the proposed system.
     37While we want to provide flexibility to the Haskell programmer, this should not come at a cost of added complexity and decreased performance. This idea reflects in the synchronization abstractions exposed to the programmer - [#PTM Primitive Transactional Memory(PTM)]), and our decision to keep certain pieces of the concurrency puzzle in the RTS ([#SafeForeignFunctionInterface Safe FFI],[#Black-holeHandling Blackholes]). One would think lifting parts of the runtime system to Haskell, and retaining other parts in C, would complicate the interactions between the concurrency primitives and schedulers. We abstract the scheduler interface using PTM monads, which simplifies the interactions. The figure below captures the key design principles of the proposed system.
    3838
    3939[[Image(GHC_LWC_Key.jpg, 100%)]]
     
    364364If an SCont is blocked with status `SContSwitched Yielded` has become unreachable, we run the SCont's finalizer, if installed.
    365365
     366== Safe-foreign Calls ==
     367
     368== PTM retry ==
     369
     370== Black-hole Handling ==
     371
    366372== Related Work ==
    367373