Changes between Version 28 and Version 29 of LightweightConcurrency


Ignore:
Timestamp:
May 17, 2012 11:37:29 PM (2 years ago)
Author:
kc
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • LightweightConcurrency

    v28 v29  
    2121For the high-level design principle for the current scheduler, see [http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Scheduler Scheduler]. 
    2222 
    23 == Design == 
    24  
    25 === Concurrency Substrate === 
     23== Concurrency Substrate == 
    2624 
    2725The idea of the concurrency substrate is to provide a minimal set of primitives over which a variety of user-level concurrency libraries can be implemented. As such, the concurrency substrate must provide a way to create threads, a way to schedule them, and a synchronization mechanism in a multiprocessor context. Whereas, the Creation and maintenance of schedulers and concurrent data structures is the task of the concurrency library. Concurrency substrate resides at [source:libraries/base/LwConc/Substrate.hs@646ec91db34c4309555fd7dd3bfe3930a4c5c55f libraries/base/LwConc/Substrate.hs]. 
    2826 
    29 ==== PTM ==== 
     27=== PTM === 
    3028 
    3129The only synchronization mechanism exposed by the concurrency substrate is a primitive transactional memory (PTM). Locks and condition variables can be notoriously difficult to use, especially in an environment with user-level threads, where they tend to interfere with the scheduler. Moreover, they do not compose elegantly with lazy evaluation. PTM interface is shown below: 
     
    4442A PTM transaction may allocate, read and write transactional variables of type `PVar a`. It is important to notice that PTM does not provide a blocking `retry` mechanism. Such a blocking action needs to interact with the scheduler, to block the current thread and resume another thread. We will see [#AbstractSchedulerInterface later] how to allow such interactions while not imposing any restriction on the structure of the schedulers. 
    4543 
    46 ==== One-shot continuations ==== 
     44=== One-shot continuations === 
    4745 
    4846The concurrency substrate enables creation and scheduling of I/O-performing computations through ''one-shot continuations''. An SCont (stack continuation) is a suspended I/O computation, which is in fact just a reference to a TSO object. Capturing the current continuation is just getting a reference to the current TSO, and hence is very fast. SCont interface is shown below: 
     
    6058Performing the body of switch atomically in a transaction avoids the nasty race conditions usually seen in multicore runtimes where one-shot continuations are used for modelling schedulers. In such systems, there are often cases where before the switch primitive has had a chance to return, another processor picks up the current continuation (appended to the scheduler) and tries to switch to it. It becomes necessary to go for complicated solutions such as releasing the scheduler locks after the target thread resumes execution to prevent races. In our case, PTM eliminates the need for such a mechanism - the other processor would not be able to access the current SCont, unless the transaction has committed and control has switched to the target SCont. Primitive `getCurrentSCont` returns a reference to the current SCont under PTM. Primitive `switchTo` commits the current PTM transaction and switches to the given SCont. As we will see, these two primitives are necessary for [#AbstractingtheScheduler abstracting the scheduler].  
    6159 
    62 ===== Return value of a switching transaction ===== 
     60==== Return value of a switching transaction ==== 
    6361 
    6462Since switchTo eagerly commits the transaction, the code that follows switchTo is not evaluated. This is a problem if the transaction that contains switchTo has a type different than PTM (). Consider the following code: 
     
    7674The type of the transaction that contains switchTo is PTM string, and atomically performing the transaction is expected to return a String value. But the value returned when the current SCont resumes execution (after switchTo) is a (). Our solution is to make switchTo return a `error "Attempting to use return value of a switched transaction"`, and any attempt to use the return value throws a runtime error. 
    7775 
    78 ==== SCont Status ==== 
     76=== SCont Status === 
    7977 
    8078Of course, care must be taken to ensure that the control does not switch to an SCont that is either running, blocked on an MVar, or completed. But how do we know whether the given SCont is ready to run? We expect the scheduler writer or library implementer to indicate the status of SCont before switching. SCont status API is show below. 
     
    9795Before a switch operation, we expect the programmer to indicate the reason for switching through setScontSwitchReason. Exception is raised by the switch primitives if switch reason has not been provided. When a switched SCont resumes execution, its status is automatically updated to `SContRunning`.  
    9896 
    99 === Capabilities and Tasks === 
     97== Capabilities and Tasks == 
    10098 
    10199Whatever 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.