The Rendezvous domain in Ptolemy II is built based on the understanding and previous implementation of the CSP (Communicating Sequential Processes) domain.
In the Rendezvous domain, there is no buffer on the communication channels between processes. The processes are implemented as Ptolemy actors running in their own threads. When two or more actors communicate via the communication channels between them, a rendezvous must be set up so that the communication starts only after all of the participating actors are ready to read or write.
Figure 1, “A simple Rendezvous model with CSP semantics” shows a very simple Rendezvous model that conforms to the original CSP semantics. Because there is no buffer, for the Ramp to output a token to the ResourcePool, both of them must be agree on the rendezvous. This means the write thread of the Ramp (the only thread of it) and the read thread of the ResourcePool must be waiting for I/O at the same time. Similarly, for the ResourcePool to output, itself and the two Displays must be ready for a rendezvous.
The Rendezvous domain extends CSP with two "transparent" actors: Merge and Barrier. These actors, unlike other actors that does either read or write in one step (I will define this later in terms of atomicity), does read and write at the same time.
Because a Merge or Barrier does read and write at the same time, the actors on both its input side and its output side participate in the same rendezvous. Figure 2, “A simple Rendezvous model with CSP semantics” depicts the simple usage of a Merge and a Barrier.
Merge. A Merge takes a token from one of its input channels, and outputs it to its single output channel. The input and the output must be satisfied at the same time. At the time of a rendezvous, if only one of its input channels has a token, it will take that token as the input; if more than one input channel is ready, it will arbitrarily take a token from the ready channels as the input.
Barrier. A Barrier takes tokens from all its input channels, and outputs them to its zero or more output channels. If it has no output channel, the tokens are simply consumed without being output. If it has output channels, the tokens from the input channels will be sent to the corresponding output channels. If it has more output channels than input channels, the token from the last input channels will be duplicated as many as needed. If it has more input channels than output channels, the tokens from the extra input channels will be discarded.
Agreement and atomicity are the core ideas of the Rendezvous domain.
First, for a rendezvous to take place, all the actors that are going to participate in it must have issued requests for read or write. However, this is a chicken and egg problem: on the one hand, to detect a rendezvous, we must know whether all the actors are ready according to the previous statement; on the other hand, to know which actors (possibly with some Merges) will participate in a rendezvous, we must detect the rendezvous first.
Second, once we detect a rendezvous, we must commit it atomically. Atomicity here means without any affecting state change in the process of the commitment. For example, there is a problem if, while a thread detects a rendezvous R1 and goes ahead to commit it, another thread also detects another rendezvous R2, and R1 and R2 have some actors in common. In this case, the two commitments conflict with each other. Only one of them should be detected and committed in a correct implementation.
Here are some imaginary models, which are considerably more complex than the ones shown above.
Here are some corner-case models with non-delay loops. A non-delay loop is a directed loop with only Merges and Barriers in it.
 Currently, each actor can utilize either one thread or 2 threads (one to read from the input ports, and the other to write to the output). It may be useful to weaken this restriction in the future.
 "Arbitrary" means "platform-dependent" in the current implementation. This will be improved in the future by means of fairness.