Channels in C++CSP2 are accessed through their ends. There are three channel-end types:
These names may seem reversed if you think of them in a channel-oriented way (because Chanin is where you take data out of the channel). However, instead think of them as process-oriented; the Chanin is where your process reads data from the channel.
The channel ends can be obtained through the reader() and writer() methods of the channels, such as One2OneChannel and BufferedOne2OneChannel. The designation of the channels details whether channels can be shared. For example, a One2OneChannel is for use by one writer and one reader. A One2AnyChannel is for one writer and any number of readers. You can read more about this on the page about Channels. It is up to you, the programmer, to make sure that these channel-ends are not used inappropriately. If you share a channel-end that should not be shared, it is likely to crash your program or cause side-effects.
You will notice that there are two types of reading channel ends; Chanin and AltChanin. The reason for this divide is because not all channels support ALTing - specifically, the shared reading-end channels (One2AnyChannel, Any2AnyChannel, BufferedOne2AnyChannel and BufferedAny2OneChannel) do not support ALTing. Therefore their reader() function provides a Chanin, whereas all the other classes return an AltChanin from their reader() method.
You will need to decide, when programming a new process, whether it should use a Chanin or an an AltChanin. The simple solution is that you should use an AltChanin if you need to ALT over the channel, but otherwise use a Chanin. That is, use the minimum that you require.
An AltChanin can be implicitly converted into a Chanin, so there is no problem in passing an AltChanin to a process that requires a Chanin. However, the reverse transformation is not possible, so a process that needs an AltChanin cannot be given a Chanin.
The other change is that the ParallelComm system has been removed. The implementation that allowed this quick optimisation has now changed, and so it became untenable to keep it. Besides which, it was always just a quick way of doing something that could be accomplished in a more generic manner.
For example, where you could previously have used a ParallelComm to communicate in parallel on two output channels (say, c and d), you should now do it as follows:
This now closely mirrors the JCSP way of accomplishing the same thing.
|class||csp::AltChanin< DATA_TYPE >|
|This class is identical to Chanin except that it also supports ALTing. More...|
|class||csp::Chanin< DATA_TYPE >|
|The reading end of a channel. More...|
|class||csp::Chanout< DATA_TYPE >|
|The writing end of a channel. More...|
|class||csp::ScopedExtInput< DATA_TYPE >|
|Provides an easy way to perform extended inputs using scope. More...|
|Returns a non-poisonable version of the given channel end.|
This can be used to supply non-poisonable channel ends to processes, for example:
One2AnyChannel<int> c; One2OneChannel<int> d; Run(new Id<int>(NoPoison(c.reader()),d.writer()));
If you call poison() on a non-poisonable channel-end, it does not poison the channel (i.e. it has no effect).
|Chanout< DATA_TYPE >||csp::NoPoison (const Chanout< DATA_TYPE > &out)|
|AltChanin< DATA_TYPE >||csp::NoPoison (const AltChanin< DATA_TYPE > &in)|
|Chanin< DATA_TYPE >||csp::NoPoison (const Chanin< DATA_TYPE > &in)|