Changes between Version 4 and Version 5 of Concurrency/DraftReportText


Ignore:
Timestamp:
Jan 16, 2007 1:31:28 PM (9 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?):