Package org.jcsp.net2

Class NetBarrier

  • All Implemented Interfaces:
    Serializable, Networked

    public final class NetBarrier
    extends Barrier
    implements Networked
    This class is a networked implementation of the standard JCSP Barrier.

    The NetBarrier is a networked version of the JCSP Barrier, a synchronization primitive similar to the standard event in CSP. The networked implementation follows the standard interface for a local Barrier, with the addition of the interface defining a networked construct. Internally, the two constructs behave differently due to the distributed nature of the NetBarrier.

    Client and Server Ends

    Unlike a normal Barrier, a NetBarrier has two types, based on whether the Barrier is the hosting end or an attached, synchronizing end. These are differentiated between as server and client ends. The server end, like the input end of a networked channel, will be declared first. The location of this server end can then be used to connect a number of client ends to. The server end can declare an initial number of expected client ends, which it waits for enrolls from before beginning any sync operations. This value can be set to 0 if need be. Each end of a barrier must also declare the number of local syncing processes, creating a two tier construct:

    Process ---> NetBarrier (client) ---> NetBarrier (server)

    Creating NetBarriers

    To create a NetBarrier, a similar method is used as a networked channel. A Barrier Name Server is provided for declaring named barriers, or the NetBarrierEnd factory can be used. First, creation of a sever end:

    int locallyEnrolled = 5;
    int remoteEnrolled = 1;
    NetBarrier bar = NetBarrierEnd.netBarrier(locallyEnrolled, remoteEnrolled);

    A client end requires the location of this barrier to allow creation:

    NetBarrierLocation loc;
    int locallyEnrolled = 5;
    NetBarrier bar = NetBarrierEnd.netBarrier(loc, locallyEnrolled);

    These barriers can then be used as normal.

    IMPLMENTATION NOTE

    To save on resources, a NetBarrier does not have an internal process controlling it (although other implementations may decide to do this). Because of this, the declaring (server) end of the barrier must always have at least one process enrolled with it to ensure that the SYNC operation occurs. If there is a danger that the enrolled processes on the server node will become 0, it is safer to define a process that is only responsible for SYNCing with the barrier. This minor overhead in certain circumstances is seen as a better approach than all NetBarriers being a process within JCSP, where processes are expensive in resources.

    public void run() {
    while (true) {
    bar.sync(); }}

    Author:
    Kevin Chalmers (networked part), P.H. Welch (Barrier)
    See Also:
    Barrier, Serialized Form
    • Method Detail

      • reset

        public void reset​(int numToEnroll)
        Resets the number of locally enrolled processes. A dangerous operation.
        Overrides:
        reset in class Barrier
        Parameters:
        numToEnroll - The number of processes to reset the enrolled to.
      • sync

        public void sync()
                  throws JCSPNetworkException
        Performs a SYNC operation with the Barrier throws JCSPNetworkException Thrown if something goes wrong in the underlying architecture
        Overrides:
        sync in class Barrier
        Throws:
        JCSPNetworkException - Thrown if something goes wrong in the underlying architecture
      • getLocation

        public NetLocation getLocation()
        Returns the location of this barrier
        Specified by:
        getLocation in interface Networked
        Returns:
        The location of this channel