1
Download Rapid Prototyping of High-Performance Concurrent Java Applications
Transcript
Chapter 4. Prototype A: Specification & Implementation of a Flawed API 19 4.2.2 Activities as Method Calls In the Proof of Concept version, method calls are used by the passive participant of an activity to call a method of the actively participating Component. This works because all shared Actions in the model contain one active and one passive participant. This is also the case with most of the example PEPA models distributed with the PEPA Workbench. Using method calls, each request has an implicit reply so the “request” and “reply” Activities can be merged. Each passive participant needs a reference to the active participant, so it can call, for example, Proxy.request(info). There is only one thread of execution in such a system, which follows the method calls through the system. For example, the client calls the proxy’s request method. This request method either returns a reply straight to the client (i.e. if it can fulfil the request), or calls the server’s request method (i.e. if the proxy can not fulfil the request). This choice is determined by a randomly generated number. When the proxy does need to call the server’s request method, the server will reply. Finally the proxy passes back the reply to the client, completing one loop of the system. The method call concept fits very nicely with traditional programming ideas but is quite different from the way a PEPA model functions. In a PEPA model, each Component is executing separately and shared activities are places in the system where multiple threads synchronise on a single action. This is also more akin to an actual clientserver relationship where both computers are executing independently. The server is idle until a request comes in. It processes the incoming request, and then becomes idle again. The original concept will work only for those PEPA models which follow the passive-active activity cooperation scheme and where one thread of execution is sufficient to capture all system behaviour. This is clearly unacceptable. 4.3 Prototype A Given these rather severe limitations, a new concept sprung to mind. The new concept allowed the system to behave much more like a genuine PEPA model and became Prototype A.
