Channels

Detailed Description

A channel is a way for processes to communicate data between each other.

A channel is a one-directional, typed communication method between processes. Because CSP principles prohibit the typical "shared data area" between processes, channels are the only way for processes to share data.

The channel objects themselves in C++CSP2 are relatively simple. The only direct action any channel allows is to get reading- and writing-ends for the channel. The channel ends are documented on the Channel Ends page.

Unbuffered Channels

The choice of channel object determines the underlying semantics of the channel. A one-to-one channel (One2OneChannel) is to be used by one writer, one reader, and is unbuffered and synchronised. That is, when a writer writes to the channel, it will not complete the write until the reader has read the value from the channel (and obviously vice versa - the reader cannot complete the read until the writer has written the value to the channel). Unbuffered Channels are also covered in the guide.

An Any2OneChannel is also unbuffered and synchronised but is for use by one reader and one or more writers. As with a One2OneChannel, the communication does not happen until both the writer and the reader attempt to communicate. However, with an Any2OneChannel, if multiple writers attempt to write to the channel, they will queue up and take it in turns to write to the channel. Each write will require the reader to perform a read.

A One2AnyChannel is again unbuffered and synchronised but is for use by one or more readers and one writer. This is not a broadcast channel. If a writer writes a piece of data to the channel, then only one reader will receieve that data. It will not replicate the data to all readers. Analogous to the Any2OneChannel, multiple readers attempting to read from the channel will queue up and take turns to read from the channel, and each reader will need the writer to perform a separate write.

An Any2AnyChannel combines the idea of an Any2OneChannel with a One2AnyChannel - it allows one or more readers and one or more writers. Each writer attempting to write will be "paired" with a single reader that is attempting to read, and a communication will be performed between the two of them. Simultaneous communications may not occur - this is only really relevant to extended rendezvous (also known as extended inputs). While an extended rendezvous is taking place on the channel, another communication will not occur, even if there is a reader and a writer both ready. In this circumstance, consider using multiple channels or not using extended inputs.

Fairness is guaranteed on shared channels (Any2.. and ..2Any channels). The exact ordering of channels may vary according to threaded nondeterminism, but a FIFO ordering is used that means that no channel end can possibly face infinite starvation in trying to use the channel. Shared channels are covered in the guide.

Some users may wonder why they should not use an Any2AnyChannel in all circumstances. Indeed, the performance hit of using an Any2AnyChannel rather than a One2OneChannel is not high. The two main reasons for not using Any2AnyChannel in every instance are:

Buffered Channels

All the channels described so far are unbuffered. C++CSP2 also contains buffered channels, with a variety of different buffering strategies available. The buffered channels are named:

Their semantics differ from the unbuffered channels solely according to the buffer that is used See the Channel Buffers module for more details. Buffered channels are also covered in the guide.

Other Channel Actions:

So far only reading and writing to a channel have been described. There are three more actions that can be performed on channels, and these are described in the following subsections.

Extended Inputs

Extended inputs, also known as extended rendezvous, are a way for a reader to perform an extended action during a communication. Extended inputs are covered in the guide. This facility is available on all unbuffered channels. It is also available on buffered channels, although its effect may not be immediately obvious - see the Channel Buffers module for more details on extended inputs on buffered channels.

ALTing

ALTing (named for the occam construct) is a way to provide choice between many (ALTernatives). It can be thought of as bearing similarity to C++'s "switch" construct, although taking this as a literal comparison may lead to confusion.

In the context of channels, ALTing is often used to read on either - say - channel A or channel B. In fact, the choice may consist of any number of channels, along with other possibilities (such as timeouts). The choice can be prioritised or fair, and more information is available on the documentation for the csp::Alternative class, and also in the Alternative section of the guide.

In the context of channels, a common question is why input guards are allowed (that is, ALTs can have a channel-read as an option) but output guards are not (that is, ALTs cannot have a channel-write as an option).

The answer to this is primarily implementation-related. Currently C++CSP2 can assume that writers to a channel are always committed (that is, once they have attempted a communication, they will always complete it, and will not "back out"), whereas readers will not always be committed (if a reader is ALTing over a channel, it is offering to communicate but may end up choosing another ready guard rather than this channel, thus backing out of the communication). This is not difficult to implement, but a system whereby both the reader and writer may back out of the communication at any time is much harder and more expensive (in terms of time and complexity) to implement.

Having said that, the new ALTing barrier mechanism recently introduced by Welch and Barnes (at CPA 2006) offers a way to implement output guards on specialised channels. I hope to be able to include such channels (that allow output guards) in C++CSP2 in the future, along with ALTing barriers.

Poison

All C++CSP2 channels support poison. Poison is a mechanism for shutting down process networks. More details can be found in the Poison module, and in the Channel Poison section of the guide.

DATA_TYPE Requirements

For One2OneChannel, One2AnyChannel, Any2OneChannel and Any2AnyChannel, DATA_TYPE* must be a valid type; DATA_TYPE cannot be a reference. DATA_TYPE must allow assignment for these channels, but no restriction is placed on the constructors.

For BufferedOne2OneChannel, BufferedOne2AnyChannel, BufferedAny2OneChannel and BufferedAny2AnyChannel, DATA_TYPE* must be a valid type (DATA_TYPE cannot be a reference). No other restrictions are technically placed by the channel; however, the Channel Buffer will impose further restrictions, which will almost certainly require at least assignment of DATA_TYPE to be possible.

C++CSP v1.x Compatibility

The channels themselves are unchanged from C++CSP v1.x. The channel ends have been changed (Chanin has been split into Chanin and AltChanin - more details on the Channel Ends page), the channel buffers have changed (more details on the Channel Buffers page), but the details provided here are the same as in version 1.x.


Classes

class  csp::Any2AnyChannel< DATA_TYPE >
 An any-to-any unbuffered channel. More...
class  csp::Any2OneChannel< DATA_TYPE >
 An any-to-one unbuffered channel. More...
class  csp::BlackHoleChannel< DATA_TYPE >
 A "one-to-none" channel. More...
class  csp::BufferedAny2AnyChannel< DATA_TYPE >
 An any-to-any buffered channel. More...
class  csp::BufferedAny2OneChannel< DATA_TYPE >
 A any-to-one buffered channel. More...
class  csp::BufferedOne2AnyChannel< DATA_TYPE >
 A one-to-any buffered channel. More...
class  csp::BufferedOne2OneChannel< DATA_TYPE >
 A one-to-one buffered channel. More...
class  csp::One2AnyChannel< DATA_TYPE >
 A one-to-any unbuffered channel. More...
class  csp::One2OneChannel< DATA_TYPE >
 A one-to-one unbuffered channel. More...
class  csp::WhiteHoleChannel< DATA_TYPE >
 A "none-to-one" channel. More...

Generated on Mon Aug 20 12:24:28 2007 for C++CSP2 by  doxygen 1.4.7