Represents a guarded communication statement in which the communication is a send(). Thus is represents
guard; send() => statements It is one branch of either a CDO or a CIF conditional communication construct.
The branches used in a conditional communication construct are controlled by the chooseBranch() method of ConditionalBranchController.
Each branch is created to perform one communication. If more than one branch is enabled (the guard is true or absent), then a thread is created for each enabled branch to try and perform the appropriate rendezvous. If the branch succeeds and is allowed to rendezvous, then it registers itself with the controller and the thread it is running in dies. Otherwise it continues to try and rendezvous until it succeeds or it is notified that another branch has succeeded in with its rendezvous, in which case this branch has failed and the thread it is running in dies.
For rendezvous, the receiver is the key synchronization point. The receiver with which this branch will try to rendezvous is set upon instantiation. It is determined from the port and channel which is passed in in the constructor.
The algorithm by which a branch determines whether or not it has succeeded with its rendezvous is executed in the run method. There are roughly three parts to the algorithm, each of which is relevant to the different rendezvous scenarios.
Case 1: There is a get already waiting at the rendezvous point. In this case the branch attempts to register itself, with the controller, as the first branch ready to rendezvous. If it succeeds, it performs the rendezvous, notifies the controller that it succeeded and returns. If it is not the first, it keeps on trying to register itself until it finally succeeds or another branch succeeds with a rendezvous in which case it fails and terminates. Note that a put cannot "go away" so it remains in an inner-loop trying to rendezvous or failing.
Case 2: There is a conditional receive waiting. In this case it tries to register both branches with their controllers as the first to try. If it succeeds it performs the transfer, notifies the controller and returns. It performs the registration in two steps, first registering this branch and then registering the other branch. If it successfully registers this branch, but cannot register the other, it unregisters itself as the first branch trying, and starts trying to rendezvous from the beginning. This is because the conditional send could "go away". If it is unable to register itself as the first branch to try, it again starts trying to rendezvous from the beginning.
Case 3: If there is neither a get or a conditional receive waiting, it sets a flag in the receiver that a conditional send is trying to rendezvous. It then waits until a get is executed on the receiver, or until another branch succeeds and this branch fails. If this branch fails, it resets the flag in the receiver, notifies the controller and returns. Note that it only needs to wait on a get as if a conditional receive is executed on the receiver, it is the branch which is responsible for checking that the rendezvous can proceed. Thus, in the case where two conditional branches are trying to rendezvous at a receiver, it is the responsibility of the branch arriving second to check that the rendezvous can proceed(see case 2).
@author Neil Smyth and Edward A. Lee
@version $Id: ConditionalSend.java,v 1.92 2007/12/07 06:28:03 cxh Exp $
@since Ptolemy II 0.2
@Pt.ProposedRating Green (eal)
@Pt.AcceptedRating Red (eal)
@see ptolemy.domains.csp.kernel.ConditionalBranch