This example describes a parallel server which can handle at maximum N requests simultaneously. Thus, when possible, for an incoming request message (received from the environment) a client process is created. The server keeps in a local variable the number of running clients. Client processes are quite simple: once created, they work for a while, and when finished they send a done message back to the server. The architecture of this application and the corresponding specification are presented in figure 1.
Basically, the specification contains several definitions. First of all, the constant N, which is a parameter for this specification, gives the maximal allowed number of clients running in parallel. Then, the signals request and done, used to communicate respectively between the server and the environment, and between the clients and the server, are defined. The signalroute es is an open (from env) communication channel transporting the requests. Finally, there are descriptions of respectively the server and client processes. The numbers after process and signalroute declarations indicate how many instances exist in the initial system configuration.
Let us focus now on the server process definition. It has one local integer variable i, counting the number of running clients. Its behavior is described by an one-state automaton with two transitions. The first transition models the reaction at the incoming requests: if the counter does not exceed the maximal allowed value, a new client is created and the counter is increased. The second transition models the reaction at termination signals by decreasing the counter. The automaton and respectively the corresponding specification are presented in figure 2.
In the server specification, the #start construct is an option string which indicates that the idle state is the initial state of the automaton. Let us remark the use of the self construct, allowing to obtain the process identifier of the server. Here, this value is then given as parameter to each new client instance created (through the fork instruction).
Finally, the figure 3 gives the specification of client processes. Once created, they perform some informal work then send back to the parent the done signal. We recall here that the communication is asynchronous point-to-point. This means that, on one hand, in order to send some message, one has to know apriori the identity of the receiver process (hence, the need for the parent parameter which stores the identity of the server, who creates the client). On the other hand, asynchronous means that the sender is never blocked by the disponibility of the receiver, the message being immediately delivered to the receiver (i.e, stored in its input-queue of pending messages). Finally, the stop construct denotes the (auto) destruction of the process instance.
