Rendezvous: Concurrency Method in JR

In this post, we’ll see a new feature of JR : the rendezvous.

Like asynchronous message passing, this synchronization method involves two processes : a caller and a receiver. But this time, the invocation is synchronous, the caller delays until the operation completes. The rendezvous does not create a new thread to the receiver. The receiver must invoke an input statement (the implementation of rendezvous) and wait for the message. Like asynchronous message passing, this is achieved using operations as message queue.

The rendezvous can simplify this kind of operations :

int x;
int y;
send op_command(2, 3);
receive(x, y);

To make a rendezvous, we use the input statement. I think it’s the harder (but also the most complete) statement of the JR programming language. Here is the general form :

inni op_command {
//Code block
}
[] op_command {
//Code block
}...

An op_command specifies an operation to wait for. An op_command is of this form :

return_type op_exp(args) st synch by sched

Explanations :

• return_type : Indicate the return type of the operation we are waiting for
• op_exp : The name of the operation or the capability
• args : The arguments of the operation
• st synch : Add a condition to the operations. This condition indicates which messages are acceptable
• by sched : Dictate the order of servicing the messages. Must be numerical. The message with the lowest value of scheduling expression will be serviced in first.

If there is no synchronization expression and no scheduling expression, the first serviced invocation is the oldest. If there is a synchronization expression, the first serviced invocation is the oldest selectable expression and if there is a scheduling expression, the first serviced is the first selectable invocation that minimizes the scheduling expression. If there is no selectable message, the input statement delays until there is one.

You can also add an else statement to the input statement :

inni op_command {
//Code block
} ...
[] else {
//Code block
}

The else block will be executed if there is no selectable message. So an input statement with an else statement will never delay.

Lets imagine a simple example. The server returns the sum of 2 numbers after receiving a message. If we write this simple program using an asynchronous message, it’ll give us something like:

public class Calculator {
	private static op void request(int x, int y);
	private static op void response(int sum, int sub);
 
	public static void main(String... args){}
 
	private static process Client {
		send request(33, 22);
 
		int sum;
		int sub;
		receive response(sum, sub);
 
		System.out.printf("Sum %d Sub %d", sum, sub);
	}
 
	private static process Server {
		int x;
		int y;
		receive request(x, y);
		send response(x + y, x - y);
	}
}

It is a little bit complicated for a thing this simple, isn’t it ? Let’s rewrite it with input statement :

public class CalculatorInni {
	private static op int compute(int x, int y);
 
	public static void main(String... args){}
 
	private static process Client {
		System.out.printf("Sum %d", compute(33, 22));
	}
 
	private static process Server {
		inni int compute(int x, int y){
			return x + y;
		}
	}
}

Easier, shorter and clearer, isn’t it ?

The Client invokes the compute operation and gets the return value directly because it’s synchronous. If you have an operation with a return value, you doesn’t have to use the call statement, it’s implicit. If you have a void operation, you can use the call statement (but if you don’t, it’s the same by default) before the operation :

call op_command(args);

And the Server has only to use the input statement to return the sum of the numbers.

As you’ve perhaps seen, the receive is only an abbreviation to the simplest form of input statement. So if you write :

int x;
int y;
receive op_command(x, y);

It’s the same as if you write :

inni void op_command(int a, int b){
      x = a;
      y = b;
}

But in this case, it’s easier to use the receive statement.

The input statement can also be used to service a group of operations in an array :

cap void (int) operations = new cap void (int)[12];
//Fill the array
 
inni ((int i = 0; i < 12; i++)) operations[i](int x) {
   //Code block
}

More than return, we could also use two new statements in an input statement :

• reply : return a value to the caller but doesn’t break the input statement, so you can still make operations in the input statement but you cannot return a value anymore.
• forward : delegate the answer to an other operation. So this is the other operation who will answer to the caller, the input statement continues its execution but cannot return a value anymore.

Now that we know how to use input statement, we can simplify the ResourceAllocator of the next post. We can do a lot more easier, with two operations and input statements :

import java.util.*;
 
public class ResourceAllocator {
	private static final int N = 25; //Number of clients
	private static final int I = 25; //Number of iterations
 
	public static void main(String... args){}
 
	private static op Resource request();
	private static op void release(Resource);
 
	private static process Client((int i = 0; i < N; i++)){
		for(int a = 0; a < I; a++){
			Resource resource = request();
 
			System.out.printf("Client %d use resource %d \n", i, resource.getId());
 
			call release(resource);
		}
	}
 
	private static process Server{
		Queue resources = new LinkedList();
 
		for(int i = 1; i <= 5; i++){
			resources.add(new Resource(i));
		}
 
		while(true){
			inni Resource request() st !resources.isEmpty() {
				return resources.poll();
			}
			[] void release(Resource resource){
				resources.add(resource);
			}
		}
	}
 
	private static final class Resource {
		private final int id;
 
		private Resource(int id){
			super();
 
			this.id = id;
		}
 
		private int getId(){
			return id;
		}
	}
}

Clearer? The last improvement we can do is to use a send instead of a call in the Client. We doesn’t need to wait for release in client and the input statement can service send invocations as well as call but the send invocations cannot return something.

So we’ve now covered the rendezvous synchronization system in the JR system. In the next, and last, post about JR programming language, we’ll see how to distribute our processes on several virtual machines.

From http://www.baptiste-wicht.com/2010/07/rendezvous-concurrency-jr/