Package org.jcsp.lang

Class BufferedAny2AnyChannelIntImpl

java.lang.Object
org.jcsp.lang.Any2AnyIntImpl
org.jcsp.lang.BufferedAny2AnyChannelIntImpl
All Implemented Interfaces:
Any2AnyChannelInt, ChannelInternalsInt

class BufferedAny2AnyChannelIntImpl extends Any2AnyIntImpl
This implements an any-to-any integer channel with user-definable buffering, safe for use by many writers and many readers.

Description

BufferedAny2AnyChannelIntImpl implements an any-to-any integer channel with user-definable buffering. It is safe for use by any number of reading or writing processes. Reading processes compete with each other to use the channel. Writing processes compete with each other to use the channel. Only the reader and one writer will actually be using the channel at any one time. This is taken care of by BufferedAny2AnyChannelIntImpl -- user processes just read from or write to it.

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

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

The constructor requires the user to provide the channel with a plug-in driver conforming to the ChannelDataStoreInt interface. This allows a variety of different channel semantics to be introduced -- including buffered channels of user-defined capacity (including infinite), overwriting channels (with various overwriting policies) etc.. 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 and writers 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 any-any channels.
See Also:
  • Constructor Details

    • BufferedAny2AnyChannelIntImpl

      public BufferedAny2AnyChannelIntImpl(ChannelDataStoreInt data)