Communication requires both participants
An asynchronous mailbox can retain a message for later processing. Rendezvous-style communication instead coordinates participants at a defined interaction point, making waiting part of the communication relation.
An unbuffered Go channel illustrates a simple form: both sender and receiver must be ready for communication to succeed. Buffering can store values before a matching receive, changing the waiting and synchronization conditions.
References: [1]
A completed handoff need not complete the business task
Unbuffered Go communication establishes specified synchronization, but a completed send does not mean the receiver’s subsequent computation has finished. Waiting for that result requires an additional result or acknowledgment relation.
An Ada task-entry rendezvous can execute a corresponding accept statement, with the caller blocked during the rendezvous and returning after the applicable accept completes. Synchronized value transfer and completion of accepted processing are therefore different contracts.
Waiting relationships affect progress
Rendezvous makes dependencies explicit but can wait indefinitely for a missing peer. Go select chooses among ready communications and waits if none can proceed and no default is present; nil channels never become ready.
Ada entry calls also have queuing, cancellation, and task-termination rules. Protocols must explain timeout and failure behavior when a peer does not appear. A rendezvous is a synchronization building block, not proof that the overall program has no circular waits.