Chan.hs 4.79 KB
Newer Older
1
{-# LANGUAGE Trustworthy #-}
2 3
{-# LANGUAGE CPP #-}

Ian Lynagh's avatar
Ian Lynagh committed
4 5 6 7 8
-----------------------------------------------------------------------------
-- |
-- Module      :  Control.Concurrent.Chan
-- Copyright   :  (c) The University of Glasgow 2001
-- License     :  BSD-style (see the file libraries/base/LICENSE)
9
--
Ian Lynagh's avatar
Ian Lynagh committed
10 11 12 13 14 15
-- Maintainer  :  libraries@haskell.org
-- Stability   :  experimental
-- Portability :  non-portable (concurrency)
--
-- Unbounded channels.
--
16 17 18 19 20
-- The channels are implemented with @MVar@s and therefore inherit all the
-- caveats that apply to @MVar@s (possibility of races, deadlocks etc). The
-- stm (software transactional memory) library has a more robust implementation
-- of channels called @TChan@s.
--
Ian Lynagh's avatar
Ian Lynagh committed
21 22 23
-----------------------------------------------------------------------------

module Control.Concurrent.Chan
24
  (
Ian Lynagh's avatar
Ian Lynagh committed
25 26 27 28
          -- * The 'Chan' type
        Chan,                   -- abstract

          -- * Operations
29 30 31 32
        newChan,
        writeChan,
        readChan,
        dupChan,
Ian Lynagh's avatar
Ian Lynagh committed
33 34

          -- * Stream interface
35 36
        getChanContents,
        writeList2Chan,
Ian Lynagh's avatar
Ian Lynagh committed
37 38 39 40
   ) where

import System.IO.Unsafe         ( unsafeInterleaveIO )
import Control.Concurrent.MVar
41
import Control.Exception (mask_)
Ian Lynagh's avatar
Ian Lynagh committed
42

43 44
#define _UPK_(x) {-# UNPACK #-} !(x)

Ian Lynagh's avatar
Ian Lynagh committed
45 46 47 48 49 50
-- A channel is represented by two @MVar@s keeping track of the two ends
-- of the channel contents,i.e.,  the read- and write ends. Empty @MVar@s
-- are used to handle consumers trying to read from an empty channel.

-- |'Chan' is an abstract type representing an unbounded FIFO channel.
data Chan a
51 52
 = Chan _UPK_(MVar (Stream a))
        _UPK_(MVar (Stream a)) -- Invariant: the Stream a is always an empty MVar
53
   deriving Eq -- ^ @since 4.4.0.0
Ian Lynagh's avatar
Ian Lynagh committed
54 55 56

type Stream a = MVar (ChItem a)

57 58 59 60
data ChItem a = ChItem a _UPK_(Stream a)
  -- benchmarks show that unboxing the MVar here is worthwhile, because
  -- although it leads to higher allocation, the channel data takes up
  -- less space and is therefore quicker to GC.
Ian Lynagh's avatar
Ian Lynagh committed
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84

-- See the Concurrent Haskell paper for a diagram explaining the
-- how the different channel operations proceed.

-- @newChan@ sets up the read and write end of a channel by initialising
-- these two @MVar@s with an empty @MVar@.

-- |Build and returns a new instance of 'Chan'.
newChan :: IO (Chan a)
newChan = do
   hole  <- newEmptyMVar
   readVar  <- newMVar hole
   writeVar <- newMVar hole
   return (Chan readVar writeVar)

-- To put an element on a channel, a new hole at the write end is created.
-- What was previously the empty @MVar@ at the back of the channel is then
-- filled in with a new stream element holding the entered value and the
-- new hole.

-- |Write a value to a 'Chan'.
writeChan :: Chan a -> a -> IO ()
writeChan (Chan _ writeVar) val = do
  new_hole <- newEmptyMVar
85 86
  mask_ $ do
    old_hole <- takeMVar writeVar
Ian Lynagh's avatar
Ian Lynagh committed
87
    putMVar old_hole (ChItem val new_hole)
88 89 90 91 92 93 94 95 96 97 98
    putMVar writeVar new_hole

-- The reason we don't simply do this:
--
--    modifyMVar_ writeVar $ \old_hole -> do
--      putMVar old_hole (ChItem val new_hole)
--      return new_hole
--
-- is because if an asynchronous exception is received after the 'putMVar'
-- completes and before modifyMVar_ installs the new value, it will set the
-- Chan's write end to a filled hole.
Ian Lynagh's avatar
Ian Lynagh committed
99

100 101 102 103 104 105 106
-- |Read the next value from the 'Chan'. Blocks when the channel is empty. Since
-- the read end of a channel is an 'MVar', this operation inherits fairness
-- guarantees of 'MVar's (e.g. threads blocked in this operation are woken up in
-- FIFO order).
--
-- Throws 'BlockedIndefinitelyOnMVar' when the channel is empty and no other
-- thread holds a reference to the channel.
Ian Lynagh's avatar
Ian Lynagh committed
107 108
readChan :: Chan a -> IO a
readChan (Chan readVar _) = do
David Feuer's avatar
David Feuer committed
109
  modifyMVar readVar $ \read_end -> do
Ian Lynagh's avatar
Ian Lynagh committed
110 111 112 113 114 115 116 117 118
    (ChItem val new_read_end) <- readMVar read_end
        -- Use readMVar here, not takeMVar,
        -- else dupChan doesn't work
    return (new_read_end, val)

-- |Duplicate a 'Chan': the duplicate channel begins empty, but data written to
-- either channel from then on will be available from both.  Hence this creates
-- a kind of broadcast channel, where data written by anyone is seen by
-- everyone else.
basvandijk's avatar
basvandijk committed
119 120 121
--
-- (Note that a duplicated channel is not equal to its original.
-- So: @fmap (c /=) $ dupChan c@ returns @True@ for all @c@.)
Ian Lynagh's avatar
Ian Lynagh committed
122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142
dupChan :: Chan a -> IO (Chan a)
dupChan (Chan _ writeVar) = do
   hole       <- readMVar writeVar
   newReadVar <- newMVar hole
   return (Chan newReadVar writeVar)

-- Operators for interfacing with functional streams.

-- |Return a lazy list representing the contents of the supplied
-- 'Chan', much like 'System.IO.hGetContents'.
getChanContents :: Chan a -> IO [a]
getChanContents ch
  = unsafeInterleaveIO (do
        x  <- readChan ch
        xs <- getChanContents ch
        return (x:xs)
    )

-- |Write an entire list of items to a 'Chan'.
writeList2Chan :: Chan a -> [a] -> IO ()
writeList2Chan ch ls = sequence_ (map (writeChan ch) ls)