Rendezvous: Difference between revisions

=={{header|Ada}}==

Ada has integrated [http://www.iuma.ulpgc.es/users/jmiranda/gnat-rts/node20.htm rendezvous support]. The caller calls to a rendezvous using the name of the task suffixed by the entry point name and the parameters. An entry point can be called using timed entry call statement which allow limit waiting time:

Server.Wake_Up (Parameters);

or delay 5.0;

-- No response, try something else

...

The task accepts a rendezvous using accept statement. The statement can contain body which implements the rendezvous. When several rendezvous need to be accepted a selective accept statement can be used. For example:

accept Wake_Up (Parameters : Work_Item) do

Current_Work_Item := Parameters;

or accept Shut_Down;

exit; -- Shut down requested

Entry points in the selective accept can be guarded by Boolean expressions which close the entry point when the expression yield false.

A task may requeue rendezvous request from the body of an accept statement to an entry point of the same or another task if the parameter profile of the entry point is compatible. The requeue statement may contain clause '''with abort'' which allows the caller to abort the request when it waits for other task to accept it. Without the clause the request is protected from abortion. This might be useful when the first task initiates processing of the request and the side effect of this action need to be removed when processing is completed.

===The task===

procedure Rendezvous is

begin

null;

Sample output:

<pre>

=={{header|AutoHotkey}}==

SetTimer, print2, 400

Else

Return -1

=={{header|C}}==

{{libheader|pthread}}

This uses POSIX threads to implement a subset of the Ada functionality and primarily focuses on the synchronization aspect. C does not have exceptions, so return values are used to signal errors. Multiple threads can enter a rendezvous at once, and a single thread can accept them. No attempt is made to implement selective accept statements or timeouts (though pthreads does have ''pthread_cond_timedwait()'').

#include <stdlib.h>

#include <stdio.h>

return 0;

}

=== OpenMP implementation ===

Basically just synched threads doing printing: since task didn't ask for service type or resource enumeration, and "message passing is stupid" (c.f. talk), the guarding thread is no more than a glorified mutex, hence completely cut out, leaving the threads directly check ink and do print.

#include <unistd.h>

#include <omp.h>

return 0;

=={{header|D}}==

std.concurrency, core.thread, core.atomic;

spawn(&humptyDumptyTask, rendezvous);

spawn(&motherGooseTask, rendezvous);

{{out}}

<pre>main: Humpty Dumpty sat on a wall.

There is no rendezvous in Erlang. To fulfil the task description I have implemented rendezvous with message passing (which is in Erlang). Doing these printers directly with message passing would have been simpler (in Erlang).

-module( rendezvous ).

printer_monitor_reserve( ok, _Reserve_pid, _Line, Pid ) -> Pid ! {printer, ok};

printer_monitor_reserve( out_of_ink, Reserve_pid, Line, Pid ) -> Reserve_pid ! {print, Line, Pid}.

{{out}}

The first printouts are there to show the identity of the processes that print. It makes it easier to match the exception to one of them and not to some other process.

It is possible to extract the boilerplate code into a reusable helper class which should be considered when using active objects a lot.

type PrinterCommand = Print of string

)).Start()

Example output:

=={{header|Go}}==

import (

}

busy.Done()

Output:

<pre>

=={{header|Julia}}==

Julia has coroutines started with the @async macro and Channels, which can be used for interprocess communication, such as passing lines to and errors from a printing routine.

inputpath::Channel{String}

errorpath::Channel{String}

schedulework([humptydumpty, oldmothergoose])

Humpty Dumpty sat on a wall.

Humpty Dumpty had a great fall.

=={{header|Nim}}==

{{trans|Python}}

type

Printer = ref object

await mainPrinter.print(gooseLines) and mainPrinter.print(humptyLines)

{{output}}

<pre>1:Old Mother Goose,

First a simple printer class whose definition is completely orthogonal to multithreading issues:

class Printer

attr ink:5

end

end

Note how requeuing the task simply becomes delegation to a different object.

Active object are not a predefined abstraction in Oz. But due to Oz' first-class object messages, we can easily define it using ports and streams (many-to-one message passing):

Obj = {New Class Init}

MsgPort

{Wait Sync}

end

This functions takes a class and an initialization message and returns a procedure. When called, this procedure will send messages to the new object in a new thread and then wait for the <code>Sync</code> variable to become bound. Exceptions are propagated using [http://www.mozart-oz.org/home/doc/base/node13.html#label696 failed values].

With this new abstraction we can create the two printers and execute both print tasks in their own thread:

Reserve = {NewActiveSync Printer init(id:2)}

in

{System.showInfo " Mother Goose out of ink!"}

end

Example output:

=={{header|Phix}}==

Phix has no rendezvous mechanism, the following achieves something similar using a simple mutex.

<span style="color: #008080;">without</span> <span style="color: #008080;">js</span> <span style="color: #000080;font-style:italic;">-- (threads)</span>

<span style="color: #008080;">constant</span> <span style="color: #000000;">print_cs</span> <span style="color: #0000FF;">=</span> <span style="color: #7060A8;">init_cs</span><span style="color: #0000FF;">()</span>

<span style="color: #7060A8;">create_thread</span><span style="color: #0000FF;">(</span><span style="color: #000000;">printer</span><span style="color: #0000FF;">,{</span><span style="color: #008000;">"mg"</span><span style="color: #0000FF;">,</span><span style="color: #000000;">mg</span><span style="color: #0000FF;">})}</span>

<span style="color: #7060A8;">wait_thread</span><span style="color: #0000FF;">(</span><span style="color: #000000;">hThreads</span><span style="color: #0000FF;">)</span>

{{out}}

<pre>

=={{header|PicoLisp}}==

Rendezvous can be implemented in PicoLisp via the following function:

(when

(catch '(NIL)

(tell Pid 'setq 'Rendezvous (lit (eval Exe)))

NIL )

The caller invokes it in the callee via the

'[http://software-lab.de/doc/refT.html#tell tell]' interprocess communication,

Use case task:

(cond

((gt0 *Ink) (prinl *ID ": " Str) (dec '*Ink))

# Prepare to terminate all processes upon exit

Output:

<pre>1: Old Mother Goose

=={{header|Python}}==

{{works with|Python|3.7}}

from __future__ import annotations

if __name__ == "__main__":

{{out}}

=={{header|Racket}}==

#lang racket

(for ([l humpty]) (send main l))

(for ([l goose]) (send main l))

Output:

main:Humpty Dumpty sat on a wall.

main:Humpty Dumpty had a great fall.

reserve:And caught the goose soon,

uncaught exception: 'out-of-ink

=={{header|Raku}}==

{{works with|Rakudo|2016.08}}

method message() { "Printer out of ink" }

}

And mounting its back,

Flew up to the moon.

{{out}}

<br>

{{works with|Tcl|8.6}}

package require Thread

# Wait enough time for the example to run and then finish

after 1000

=={{header|Wren}}==

This uses fibers, which are always synchronous in Wren, to simulate the rendezvous mechanism.

construct new(id, ink) {

_id = id

}

if (tasks.all { |task| task.isDone }) return

{{out}}

{{trans|D}}

It is unfortunate the critical section is so long but there are several intertwined objects that can only be changed as a unit.

const TEXT="Out of ink";

text=TEXT; // rename IOError to OutOfInk for this first/mother class

}

}

try{ foreach line in (vm.arglist[2,*]){ rendezvous.print(line); } }

catch{ println(taskNm," caught ",__exception); } // and thread quits trying to print

"And mounting its back,", "Flew up to the moon."

)

humptyDumptyTask.launch(rendezvous);

motherGooseTask.launch(rendezvous);

{{out}}

<pre>