Package org.jcsp.lang

Class One2AnyChannelImpl<T>

java.lang.Object
org.jcsp.lang.One2AnyImpl<T>
org.jcsp.lang.One2AnyChannelImpl<T>
All Implemented Interfaces:
ChannelInternals<T>, One2AnyChannel<T>

class One2AnyChannelImpl<T> extends One2AnyImpl<T>
This implements a one-to-any object channel, safe for use by one writer and many readers.

Description

One2AnyChannel is an implementation of a channel which is safe for use by many reading processes but only one writer. Reading processes compete with each other to use the channel. Only one reader and the writer will actually be using the channel at any one time. This is taken care of by One2AnyChannel -- user processes just read from or write to it.

Please note that this is a safely shared channel and not a broadcaster. Currently, broadcasting has to be managed by writing active processes (see DynamicDelta for an example).

All reading processes and the writing process commit to the channel (i.e. may not back off). This means that the reading processes may not ALT on this channel.

The default semantics of the channel is that of CSP -- i.e. it is zero-buffered and fully synchronised. A reading process must wait for the matching writer and vice-versa.

A factory pattern is used to create channel instances. The create methods of Channel allow creation of channels, arrays of channels and channels with varying semantics such as buffering with a user-defined capacity or overwriting with various policies. Standard examples are given in the org.jcsp.util package, but careful users may write their own.

Implementation Note and Caution

Fair servicing of readers to this channel depends on the fair servicing of requests to enter a synchronized block (or method) by the underlying Java Virtual Machine (JVM). Java does not specify how threads waiting to synchronize should be handled. Currently, Sun's standard JDKs queue these requests - which is fair. However, there is at least one JVM that puts such competing requests on a stack - which is legal but unfair and can lead to infinite starvation. This is a problem for any Java system relying on good behaviour from synchronized, not just for these 1-any channels.
See Also:
  • Constructor Details

    • One2AnyChannelImpl

      One2AnyChannelImpl()