chp-1.7.1: An implementation of concurrency ideas from Communicating Sequential Processes

Control.Concurrent.CHP.Channels.BroadcastReduce

Description

A module containing broadcast channels (one-to-many). Whereas a one-to-any channel features one writer sending a single value to one (of many) readers, a one-to-many channel features one writer sending the same value to many readers. So a one-to-any channel involves claiming the channel-end to ensure exclusivity, but a one-to-many channel involves enrolling on the channel-end (subscribing) before it can engage in communication.

A communication on a one-to-many channel only takes place when the writer and all readers currently enrolled agree to communicate. What happens when the writer wants to communicate and no readers are enrolled was undefined in versions 1.5.1 and earlier (the writer may block, or may communicate happily to no-one). However, in version 1.6.0 onwards the semantics are clear: a writer that communicates on a broadcast channel with no readers involved will succeed immediately, communicating to no-one (i.e. the data is lost). Similarly, a read from a reduce channel will immediately return mempty when no writers are enrolled. It is possible to get into a state of livelock (by repeatedly performing these instant communications) in these sorts of situations.

This module also contains reduce channels (added in version 1.1.1). Because in CHP channels must have the same type at both ends, we use the Monoid type-class. It is important to be aware that the order of mappends will be non-deterministic, and thus you should either use an mappend that is commutative or code around this restruction.

For example, a common thing to do would be to use lists as the type for reduce channels, make each writer write a single item list (but more is possible), then use the list afterwards, but be aware that it is unordered. If it is important to have an ordered list, make each writer write a pair containing a (unique) index value and the real data, then sort by the index value and discard it.

Since reduce channels were added after the initial library design, there is a slight complication: it is not possible to use newChannel (and all similar functions) with reduce channels because it is impossible to express the Monoid constraint for the Channel instance. Instead, you must use manyToOneChannel and manyToAnyChannel.

Synopsis

Documentation

data BroadcastChanin a Source

The reading end of a broadcast channel. You must enroll on it before you can read from it or poison it.

The Eq instance was added in version 1.4.0.

data BroadcastChanout a Source

The writing end of a broadcast channel.

The Eq instance was added in version 1.4.0.

oneToManyChannel' :: MonadCHP m => ChanOpts a -> m (OneToManyChannel a)Source

Added in version 1.5.0.

In versions 1.5.0-1.7.0, the broadcast and reduce channels do not appear correctly in the traces.

anyToManyChannel' :: MonadCHP m => ChanOpts a -> m (AnyToManyChannel a)Source

Added in version 1.5.0.

In versions 1.5.0-1.7.0, the broadcast and reduce channels do not appear correctly in the traces.

data ReduceChanin a Source

The reading end of a reduce channel.

The Eq instance was added in version 1.4.0.

data ReduceChanout a Source

The writing end of a reduce channel. You must enroll on it before you can read from it or poison it.

The Eq instance was added in version 1.4.0.

sameReduceChannel :: ReduceChanin a -> ReduceChanout a -> BoolSource

The reduce channel version of sameChannel.

This function was added in version 1.4.0.

manyToOneChannel' :: (Monoid a, MonadCHP m) => ChanOpts a -> m (ManyToOneChannel a)Source

Added in version 1.5.0.

In versions 1.5.0-1.7.0, the broadcast and reduce channels do not appear correctly in the traces.

manyToAnyChannel' :: (Monoid a, MonadCHP m) => ChanOpts a -> m (ManyToAnyChannel a)Source

Added in version 1.5.0.

In versions 1.5.0-1.7.0, the broadcast and reduce channels do not appear correctly in the traces.