Changes between Version 52 and Version 53 of LightweightConcurrency


Ignore:
Timestamp:
May 19, 2012 2:49:15 AM (2 years ago)
Author:
kc
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • LightweightConcurrency

    v52 v53  
    238238As an aside, the race condition in [http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Concurrent-MVar.html#v%3AswapMVar swapMVar] can be eliminated with the help of PTM abstraction. TODO: show example. Thus, PTM abstraction makes it easy to construct correct concurrent data-structures.  
    239239 
    240 == SCont Affinity == 
     240== Capabilities and Tasks == 
     241 
     242Whatever be the concurrency model, we would like to retain the non-programmatic control over parallelism (using +RTS -N). Just like in the current system, this runtime parameter controls the number of capabilities. Cores are system resources and hence, the control over their allocation to different processes should be a property of the context under which the programs are run. For example, in a multi-programmed environment, it might be wiser to run the programs on a fewer cores than available to avoid thrashing. At the very least, this will avoid the cases where a poorly written concurrency library would not bring down the performance of the entire system.  
     243 
     244We retain the task model of the current runtime system. There is a one-to-one mapping between tasks and system threads. Tasks are not exposed to the programmer and is transparently managed by the RTS. 
     245 
     246=== SCont Affinity === 
    241247 
    242248Every SCont is bound to a particular capability and only that capability is capable of running the SCont. Switching to an SCont that is not bound to the current capability raises a runtime error. SCont affinity interface is shown below. 
    243249 
    244250{{{ 
    245 }}} 
    246  
    247 A newly created SCont is bound to the current capability.  
    248  
    249  
    250 == Capabilities and Tasks == 
    251  
    252 Whatever be the concurrency model, we would like to retain the non-programmatic control over parallelism (using +RTS -N). Just like in the current system, this runtime parameter controls the number of capabilities. Cores are system resources and hence, the control over their allocation to different processes should be a property of the context under which the programs are run. For example, in a multi-programmed environment, it might be wiser to run the programs on a fewer cores than available to avoid thrashing. At the very least, this will avoid the cases where a poorly written concurrency library would not bring down the performance of the entire system. 
    253  
    254 We retain the task model of the current runtime system. There is a one-to-one mapping between tasks and system threads. A bound SCont has its own bound task, which is the only task capable of running the bound SCont. However, an unbounded SCont might be run on any unbounded task (referred to as worker tasks). New worker tasks are created whenever the number of available tasks is less than the number of capabilities. 
    255  
     251setSContCapability :: SCont -> Int -> IO () 
     252getSContCapability :: SCont -> PTM Int 
     253}}} 
     254 
     255A newly created SCont is bound to the current capability. Primitive `setSContCapability` is used to change the affinity of an SCont that belongs to the current capability. Trying to change the affinity of an SCont that belongs to a different capability throws a runtime error.  
     256 
     257=== Bound SCont === 
     258 
     259Similar to [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#g:9 bound threads] concurrency substrate supports bound SConts. The interface is shown below. 
     260 
     261{{{ 
     262newBoundSCont          :: IO () -> IO SCont 
     263isCurrentSContBound    :: IO Bool 
     264rtsSupportsBoundSConts :: Bool 
     265}} 
     266 
     267Creating a bound SCont creates a new task, which is the only task capable of running the bound SCont. When switching to a bound SCont, the RTS transparently switches to the corresponding bound task. Similarly, when switching away from a bound SCont, the RTS suspends the current bound task, and switches to another appropriate task. However, an unbounded SCont (created through `newSCont` primitive) might be run on any unbounded task (referred to as worker tasks). New worker tasks might be created by the RTS on demand. 
    256268 
    257269== Related Work ==