Rendezvous: Difference between revisions

Content added Content deleted
(added F#)
({{omit from|PARI/GP}})
Line 3: Line 3:
Demonstrate the “rendezvous” communications technique by implementing a printer monitor.
Demonstrate the “rendezvous” communications technique by implementing a printer monitor.
==Detailed Description of Programming Task==
==Detailed Description of Programming Task==
Rendezvous is a synchronization mechanism based on procedural decomposition. Rendezvous is similar to a procedure call with the difference that the caller and the callee belong to different [[task|tasks]]. The called procedure is usually called an '''entry point''' of the corresponding [[task]]. A call to an entry point is synchronous, i.e. the caller is blocked until completion. For the caller a call to the entry point is indivisible. Internally it consists of:
Rendezvous is a synchronization mechanism based on procedural decomposition. Rendezvous is similar to a procedure call with the difference that the caller and the callee belong to different [[task]]s. The called procedure is usually called an '''entry point''' of the corresponding task. A call to an entry point is synchronous, i.e. the caller is blocked until completion. For the caller a call to the entry point is indivisible. Internally it consists of:


* Waiting for the callee ready to accept the rendezvous;
* Waiting for the callee ready to accept the rendezvous;
* Engaging the rendezvous (servicing the entry point).
* Engaging the rendezvous (servicing the entry point).


The caller may limit the waiting time to the callee to accept the rendezvous. I.e. a rendezvous request can be aborted if not yet accepted by the callee. When accepted the rendezvous is processed until its completion. During this time the caller and the callee [[task|tasks]] stay synchronized. Which context is used to process the rendezvous depends on the implementation which may wish to minimize context switching.
The caller may limit the waiting time to the callee to accept the rendezvous. I.e. a rendezvous request can be aborted if not yet accepted by the callee. When accepted the rendezvous is processed until its completion. During this time the caller and the callee tasks stay synchronized. Which context is used to process the rendezvous depends on the implementation which may wish to minimize context switching.


The callee [[task]] may accept several rendezvous requests:
The callee task may accept several rendezvous requests:


* Rendezvous to the same entry point from different tasks;
* Rendezvous to the same entry point from different tasks;
Line 19: Line 19:
Language mechanism of [[exceptions]] (if any) has to be consistent with the rendezvous. In particular when an exception is propagated out of a rendezvous it shall do in both tasks. The exception propagation is synchronous within the rendezvous and asynchronous outside it.
Language mechanism of [[exceptions]] (if any) has to be consistent with the rendezvous. In particular when an exception is propagated out of a rendezvous it shall do in both tasks. The exception propagation is synchronous within the rendezvous and asynchronous outside it.


An engaged rendezvous can be requeued by the callee to another entry point of its [[task]] or to another [[task]], transparently to the caller.
An engaged rendezvous can be requeued by the callee to another entry point of its task or to another task, transparently to the caller.


Differently to messages which are usually asynchronous, rendezvous are synchronous, as it was stated before. Therefore a rendezvous does not require marshaling the parameters and a buffer to keep them. Further, rendezvous can be implemented without context switch. This makes rendezvous a more efficient than messaging.
Differently to messages which are usually asynchronous, rendezvous are synchronous, as it was stated before. Therefore a rendezvous does not require marshaling the parameters and a buffer to keep them. Further, rendezvous can be implemented without context switch. This makes rendezvous a more efficient than messaging.
Line 792: Line 792:
{{omit from|E}} <!-- Not in the spirit of E concurrency; would be unenlightening to implement -->
{{omit from|E}} <!-- Not in the spirit of E concurrency; would be unenlightening to implement -->
{{omit from|JavaScript}} <!-- As yet, no multitasking unless you count setTimeout or multiple pages -->
{{omit from|JavaScript}} <!-- As yet, no multitasking unless you count setTimeout or multiple pages -->
{{omit from|TI-83 BASIC}} {{omit from|TI-89 BASIC}} <!-- Does not have concurrency or background processes. -->
{{omit from|PARI/GP|No concurrency or access to devices}}
{{omit from|Retro}} <!-- no concurrency in the standard implementations -->
{{omit from|Retro}} <!-- no concurrency in the standard implementations -->
{{omit from|TI-83 BASIC}} {{omit from|TI-89 BASIC}} <!-- Does not have concurrency or background processes. -->


==See also==
==See also==