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.
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:
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.
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.
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.
|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...|