Lably
Skip to content

Join-pattern

Software design pattern for parallel computing

  • 49 min read
  • 7 chapters

Related on Lably

Through Distributed computing, Message passing and Pattern matching

This template is based on join-calculus and uses pattern matching. Concretely, this is done by allowing the join definition of several functions and/or channels by matching concurrent call and messages patterns. It is a type of concurrency pattern because it makes easier and more flexible for these entities to communicate and deal with the multi-threaded programming paradigm.

Description

The join-pattern (or a chord in Cω) is like a super pipeline with synchronisation and matching. In fact, this concept is summarise by match and join a set of message available from different message queues, then handles them all simultaneously with one handler. It could be represented by the keywords when to specify the first communication that we expected, with the and to join/pair other channels and the do to run some tasks with the different collected messages. A constructed join pattern typically takes this form:

<span id="mwIQ"></span>j.When(a1).And(a2). ... .And(an).Do(d)

Argument a1 of When(a1) may be a synchronous or asynchronous channel or an array of asynchronous channels. Each subsequent argument ai to And(ai) (for i > 1) must be an asynchronous channel.

More precisely, when a message matches with a chain of linked patterns causes its handler to run (in a new thread if it's in asynchronous context) otherwise the message is queued until one of its patterns is enabled; if there are several matches, an unspecified pattern is selected.

Unlike an event handler, which services one of several alternative events at a time, in conjunction with all other handlers on that event, a join pattern waits for a conjunction of channels and competes for execution with any other enabled pattern.

Join-pattern is defined by a set of pi-calculus channels x that supports two different operations, sending and receiving, we need two join calculus names to implement it: a channel name x for sending (a message), and a function name x for receiving a value (a request). The meaning of the join definition is that a call to x() returns a value that was sent on a channel x<>. Each time functions are concurrently, triggers the return process and synchronizes with other joins.

<span id="mwSg"></span><span class="n" id="mwSw">J</span><span class="w" id="mwTA"> </span><span class="o" id="mwTQ">::=</span><span class="w" id="mwTg"> </span><span class="c1" id="mwTw">//join patterns</span> <span class="err" id="mwUA">|</span><span class="w" id="mwUQ"> </span><span class="n" id="mwUg">x</span><span class="o" id="mwUw"><</span><span class="n" id="mwVA">y</span><span class="o" id="mwVQ">></span><span class="w" id="mwVg"> </span><span class="c1" id="mwVw">//message send pattern</span> <span class="err" id="mwWA">|</span><span class="w" id="mwWQ"> </span><span class="n" id="mwWg">x</span><span class="p" id="mwWw">(</span><span class="n" id="mwXA">y</span><span class="p" id="mwXQ">)</span><span class="w" id="mwXg"> </span><span class="c1" id="mwXw">//function call pattern</span> <span class="err" id="mwYA">|</span><span class="w" id="mwYQ"> </span><span class="n" id="mwYg">J</span><span class="w" id="mwYw"> </span><span class="err" id="mwZA">|</span><span class="w" id="mwZQ"> </span><span class="n" id="mwZg">JBIS</span><span class="w" id="mwZw"> </span><span class="c1" id="mwaA">//synchronization</span>

From a client’s perspective, a channel just declares a method of the same name and signature. The client posts a message or issues a request by invoking the channel as a method. A continuation method must wait until/unless a single request or message has arrived on each of the channels following the continuation’s When clause. If the continuation gets to run, the arguments of each channel invocation are dequeued (thus consumed) and transferred (atomically) to the continuation’s parameters.

In most of cases, the order of synchronous calls is not guaranteed for performance reasons. Finally, during the match the messages available in the queue could be stolen by some intervening thread; indeed, the awakened thread may have to wait again.

Sign in to keep reading

6 more chapters are free with a Lably account.

More in Computing and communication