| by: | Burt Rosenberg |
| at: | university of miami |
| last-update: | 5 oct 2024 |
| 28 sep 2026 |
We define the rendez-vous and use PV semaphores to implement the rendez-vous. The idea is two threads should proceed to a certain location in their code, and wait until all threads have arrived at that point.
The threads proceed concurrently, that is, the events in the threads occur without any required ordering relationship between the threads. Events S and T can be ordered by the time at which they occurred. If S occurs before T in time we write S <t T.
If the ordering of the evens S and T is guaranteed, we call S and T synchronous events and write S < T.
Within a thread, it is easy to establish what events are synchronous, as the line by line execution of the the code provides this ordering.
It might be required that a time ordering be established (or more generally, some dependency) between and S and T in different threads, say A and B. One solution is the rendez-vous. A Rendez-vous is an event R known to both threads and for any synchronous fact,
as well. Then R can be any time greater than the later of SA and SB and the earliest of TA, TB.
A Rendez-Vous at R for threads A and B
SA R TA
| | |
A: ----+-----+--+--------------
|
|
B: -------+--+-----+-----
| | |
SB R TB
~~~ X ~~~ my.V() ~~~~~~~~ other.P() ~~~~~~~ Y ~~~~~~~~
and likewise for thread B,
Note that the event P will mean the succesful moving on from the P call.
Because of the PV semaphores we have,
This is because, no matter when A begins the A:P event, it will not proceed until thread B signals A's semaphore, that is, after the B:V event. Likewise fo the B:P event.
Therefore we have
and
A: X R Y
| | |
t: ---+--+----+--------+---+-----
| | |
B: X R Y

author: burton rosenberg
created: 5 oct 2024
update: 28 sep 2026