Changes between Version 4 and Version 5 of Concurrency/DraftReportText


Ignore:
Timestamp:
Jan 16, 2007 1:31:28 PM (8 years ago)
Author:
simonmar@…
Comment:

MVars

Legend:

Unmodified
Added
Removed
Modified
  • Concurrency/DraftReportText

    v4 v5  
    3939== Communication between Threads == 
    4040 
    41 '''ToDo''': MVars or STM. 
     41The basic facility for communication between threads is the `MVar` type. 
    4242 
    43 MVars have important properties that can't be simulated in STM: fairness and single-wakeup.  (only the first is important from a semantics perspective, the second has significant practical importance though). 
     43{{{ 
     44data MVar  -- instance of Eq, Typeable, Typeable1 
     45}}} 
     46 
     47An MVar (pronounced "em-var") is a synchronising variable. It can be thought of as a a box, which may be empty or full.  An `MVar` may be created using one of the following two operations: 
     48 
     49{{{ 
     50newEmptyMVar :: IO (MVar a) 
     51newMVar :: a -> IO (MVar a) 
     52}}} 
     53 
     54`newEmptyMVar` create an MVar which is initially empty; `newMVar` create an MVar which contains the supplied value. 
     55 
     56{{{ 
     57takeMVar :: MVar a -> IO a 
     58}}} 
     59 
     60The `takeMVar` operation return the contents of the `MVar`. If the `MVar` is currently empty, `takeMVar` will block until it is full. After a `takeMVar`, the `MVar` is left empty. 
     61 
     62{{{ 
     63putMVar :: MVar a -> a -> IO () 
     64}}} 
     65 
     66Put a value into an `MVar`. If the `MVar` is currently full, `putMVar` will wait until it becomes empty. 
     67 
     68There is an extension to the fairness guarantee as it applies to `MVar`s: 
     69 
     70 * A thread blocked on an `MVar` will eventually proceed, as long as the `MVar` is being filled infinitely often. 
     71 
     72It is recommended that the implementation provide "single-wakeup" semantics for `takeMVar`.  That is, if there are multiple threads 
     73blocked in `takeMVar` on a particular `MVar`, and the `MVar` becomes full, only one thread will be woken up. The implementation   
     74guarantees that the woken thread completes its `takeMVar` operation.  In fact, a single-wakeup implementation is usually a consequence of providing the fairness extension for `MVar`s above: if multiple threads blocked on an `MVar` were woken up simultaneously, it would be hard to guarantee that any particular thread would eventually gain access to the `MVar`. 
     75 
     76'''ToDo''' STM? 
    4477 
    4578== Concurrency and the FFI == 
     
    88121Note that a valid implementation of bound threads is one in which every Haskell thread is associated with a distinct OS thread, where in effect every thread is bound.  However, the `isCurrentThreadBound` operation (see below) should always return `False` for threads created by `forkIO`, regardless of the implementation, to aid portabilty. 
    89122 
    90 Also note that the above property of foreign calls made by a bound thread is the ''only'' requirement of the relationship between OS threads and Haskell threads.  It is completely unspecified which OS thread runs the Haskell code itself: the implementation is free to choose among a number of strategies here. 
     123Also note that the above property of foreign calls made by a bound thread is the ''only'' requirement of the relationship between OS threads and Haskell threads.  It is completely unspecified which OS thread runs the Haskell code itself: the Haskell programmer has no way to observe the current OS thread aside from making a foreign call, so the implementation is free to choose among a number of strategies here. 
    91124 
    92125The following operations exported by `Control.Concurrent` are related to bound threads ('''ToDo''' just link to the appropriate section of the library docs here?):