Class NetBarrier
- All Implemented Interfaces:
Serializable, Networked
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:
-
Method Summary
Modifier and TypeMethodDescriptionvoiddestroy()Destroys the Barriervoidenroll()Enrolls locally with the BarrierReturns the location of this barriervoidreset(int numToEnroll) Resets the number of locally enrolled processes.voidresign()Resigns an local process from the barriervoidsync()Performs a SYNC operation with the Barrier throws JCSPNetworkException Thrown if something goes wrong in the underlying architecture
-
Method Details
-
reset
-
sync
Performs a SYNC operation with the Barrier throws JCSPNetworkException Thrown if something goes wrong in the underlying architecture- Overrides:
syncin classBarrier- Throws:
JCSPNetworkException- Thrown if something goes wrong in the underlying architecture
-
enroll
Enrolls locally with the Barrier- Overrides:
enrollin classBarrier- Throws:
JCSPNetworkException- Thrown if the barrier is not a state where it can be enrolled with
-
resign
Resigns an local process from the barrier- Overrides:
resignin classBarrier- Throws:
JCSPNetworkException- Thrown if something bad happens within the underlying architecture
-
destroy
Destroys the Barrier- Specified by:
destroyin interfaceNetworked- Throws:
JCSPNetworkException- Thrown if something goes wrong in the underlying architecture
-
getLocation
Returns the location of this barrier- Specified by:
getLocationin interfaceNetworked- Returns:
- The location of this channel
-