DCP: A Case Study in Distributed Programming with Domains? Marc Lacoste France Telecom R & D
[email protected]
Abstract. Building reliable distributed applications involving multiple concerns such as security, fault-
tolerance or real-time properties still remains a challenge. A \provably correct" formal approach, i.e., using a carefully designed model with a well-de ned semantics and an implementation that strictly conforms to the model, brings obvious bene ts in terms of reliability and clean design. In this paper, by using the notion of domain to capture partitions in a distributed system, we illustrate that approach on a case-study by showing the di erent formalization steps from model design to implementation. We present a simple distributed programming model called dcp that extends Pict with primitives for remote interaction. dcp makes the distribution of resources explicit while keeping network communications transparent to the programmer. We formalize its implementation in the form of an abstract machine and implement it using standard distributed system technology by integrating seamlessly a distributed runtime with the jonathan object platform which provides support for network transparent communications.
1 Introduction As requirements for distributed applications get tighter in terms of exibility and reliability, software architects face the task of designing applications which should be simultaneously secure, fault-tolerant but may also demand real-time or transactional properties. Although concern-speci c solutions are available, the overall application design remains a challenge. Formal methods address such dependability issues by providing hints as how to cleanly design such applications, and methodologies to validate them in the long run. Although today's distributed object technologies such as Java or CORBA have reached a certain degree of maturity, they do not lend themselves easily to formalism. Thus, using a carefully designed model with a well-de ned semantics for distributed mobile programming and an implementation that strictly conforms to the model would bring obvious bene ts in terms of reliability and correctness. This is the general approach adopted in the MARVEL project which introduces the notion of domain to help capture partitions in a distributed system. The project aims to de ne a core programming model in the form of a distributed process calculus, and to specify and implement a provably correct virtual machine realizing the model. In this paper, we test that overall approach on a simple programming model. In particular, we present the speci cation of a distributed virtual machine and its implementation using standard distributed system technology. A high-level functional language for concurrent programming like Pict [8] seemed a good starting point for such an experiment, since its theoretical foundations are particularly well-de ned : Pict is built on top of a minimal calculus called Core Pict which can be totally implemented in terms of -calculus primitives. For instance, Turner [8] formalized a concurrent implementation of Pict in the form of an abstract machine (AM) and proved it to be correct with respect to the calculus. However, Pict does not take address distribution issues. The goal of this work is to illustrate on a distributed version of Pict the various formalization steps in a provably correct approach, ranging from the design of a distributed programming model taking a minimalist view of domains, to its implementation. In this paper, we make the following contributions: We extend the Core Pict calculus to include a simple form of domain and remote interaction primitives. Our new programming model called dcp for Distributed Core Pict makes the distribution of resources explicit, while keeping network communications transparent to the programmer. We formalize an implementation of the model in the form of a distributed AM. We implement that formal speci cation with a distributed runtime written in Java, and seamlessly integrate it with the jonathan [2] ORB (Object Request Broker) framework which provides support for network transparent communications. The rest of the paper is organized as follows. Sect. 2 clari es the notion of domain. Sect. 3 discusses related work. Sect. 4, 5 and 6 then present the dcp programming model, the formal speci cation, and its distributed implementation. ?
This work is partly supported by the RNRT project MARVEL 98S0347
2 Domains The dcp programming model is organized around the notion of domain which captures many situations of distributed mobile programming: \a distributed system should primarily be understood as a partitioned system. Sub-systems and components of a distributed system can be grouped in di erent, possibly overlapping sets, generally under the control of a single object or entity. [ : : : ] We shall call domains such sets of sub-systems or components" [4]. Domains come into di erent varieties: security, naming, technology, administrative, or failure domains are just but a few. That core concept has the potential to trigger a new style of programming by combining di erent domain types within a single programming language. This appears, however, as a long term research goal. In the dcp experiment, we introduce a simpler form of domain by making physical distribution explicit in an asynchronous -calculus. Such domains range from subnets to a UNIX process running a Java Virtual Machine. We adopt a at domain topology.
3 Related Work A number of distributed process calculi such as Nomadic Pict [7], DiTyCO [6], or the join-calculus [3] introduce constructs similar to domains in terms of sites, systems or locations. In dcp, remote interaction is primitive, the distribution of resources made explicit, while keeping network communications transparent. We now brie y motivate those design decisions and compare them with other solutions found in related work: Remote Interaction. dcp includes remote message send constructs rather than process migration facilities as core features of the model, choice which seems more realistic in terms of implementation costs. Another alternative found in [7] and [6] is the \move and communicate" (M&C) semantics: remote interaction is viewed as a high-level construct, transparent to the location of the recipient, and can be encoded with low-level primitives of process migration and local communication. Thus, true communication is always purely local. By contrast, in [3], remote interaction is a primitive distinct from process migration, the M&C semantics being expressed in terms of migration of messages and not of processes. Routing. dcp uses network transparent names which make implicit routing possible as in [3]. A di erent solution [6] is to distinguish at the syntax-level between local and remote names. Formalizing the Implementation. The dcp AM extends the one proposed by Turner for Pict by including remote interaction primitives, and is one of the rst attempts to formalize a distributed implementation of a process calculus in the form of a distributed AM. The approach of [6] is similar, but the AM is only presented in a non-distributed setting. However, it allows the execution of multiple threads. In [7], a distributed infrastructure is formalized by a formal translation from a high-level language to a low-level calculus. Process mobility is also supported. The approach followed in dcp to integrate an AM a la Pict with an ORB, appears to be novel. Thus, it allows us to combine the strength of functional programming techniques used to implement [3], or [7] with the object-oriented framework provided by CORBA-like technologies.
4
dcp
: A Simple Model for Distributed Programming
4.1 Syntax
The dcp model represents a distributed system with a limited number of abstractions, namely con gurations, domains, processes, and channels. A con guration C; D : : : may be understood as a parallel composition of domains a[P ], and of messages hx; y~i being routed between those domains. An idle system is represented by the inert con guration nil. A domain brings together inside a single scope basic computational units called processes : the a[P j Q j : : : ] term represents a domain a hosting several processes P ,Q,: : : running in parallel. We introduce two separate parallel composition operators, k for con gurations, and j for processes running inside a domain scope. Inter-process communication, both within and between domains, is based on asynchronous message passing on channel names. Those rst class values m; n; x; y : : : may be transmitted on other channels causing the communication topology to evolve dynamically. The dcp syntax includes a single notion of name which encompasses local names, only valid inside a single domain, and network names, valid throughout the distributed system. Process-related operations are closely inspired from Core Pict, and include standard -calculus constructs such as the inert process 0, conditional testing for equality of values, parallel composition P j Q, channel name creation (n)P { the scope of name n being restricted to that of process P { or replication P which creates an unbounded number of copies of P running in parallel. Finally, two processes communicate on some channel x using the x!hy~i and x?(~y):P primitives, respectively for the output and input of the tuple of values y~, the execution resuming as P after the reception. The abstract syntax of the calculus is given in gure 3 at the end of the paper.
4.2 Operational Semantics The operational semantics of dcp, given in appendix, features a structural equivalence and a reduction relation ! compatible with . Thus, terms can be syntactically rearranged to bring together those which can be reduced, as expressed in the metaphor of [1], where terms are seen as molecules in a chemical soup. The various computation rules are only described informally but are described more precisely in a companion technical report to appear. Structural equivalence is a congruence on processes and con gurations, being compatible with the name restriction, parallel composition, reception, and replication operators, but also with the domain construct. The other rules de ne the behaviour of the replication operator, or show how names can be freely communicated outside the scope of a domain, or of a parallel composition of processes or con gurations. In terms of computation, we have the usual rules for conditionals, as well as the possibility to make reductions under the name restriction, parallel composition, or domain constructs. The communication semantics of dcp in terms of local and remote interaction between processes is de ned as follows:
Intra-domain communications are performed as in the asynchronous -calculus using the (com) rule:
the interaction on some channel m of sender and receiver processes S = m!hv~i and R = m?(~u):P reduces in the continuation of the receiver where the formal arguments u~ are replaced by the values v~ sent by S . Inter-domain communications are captured by rules (send) and (receive): if the target receiver m is located in a remote domain, i.e., is not contained in the set of free receivers dn(P ) found in current domain a[P j : : : ], the sender process is removed from a, and a message is sent outside the scope of a containing the values to send on m. Conversely, if an incoming message is targeted at a local receiver, the message is consumed, and a sender process is created inside the current domain scope. The interaction terminates by a local communication.
5 A Formal Speci cation for a dcp Abstract Machine We now formalize an implementation of dcp in the form of a distributed AM. We only discuss the machine informally, the main formal de nitions of the machine being collected in gure 4. Each dcp domain is implemented by an AM which may be viewed as an object S = (a; U; V; H; R): a is the machine name which designates the AM in a unique way. U and V are two sets of names that represent the local and remote channel names known by the machine during its execution. H is the heap which behaves as a communication bu er. It maps channel names x to FIFO channel queues H (x) containing input rd or output processes wr blocked on a communication on x. We have x 2 U for a local communication, and x 2 V for a remote one. R is the run queue which contains processes ready for execution, the one at the head of the queue being run rst. Newly created processes will generally be placed at the end of the run queue, to guarantee a fairness of execution property. Thus, a general dcp con guration is implemented by a parallel composition of AM and of messages. To manage distribution, we need to re ne the single notion of name found in the calculus. We introduce the notion of pickled name to represent a network-level name. It is an abstraction both of an on-the-wire representation of the name viewed as a communication capability, and of the underlying communication resources necessary for a remote interaction to occur. Formally, we assume given two name transformation operations pickle and unpickle : pickle(a; x) returns a pickled name corresponding to a local name x created in domain a. Conversely, unpickle(x) returns a pair (a; y): pickled name x is resolved into a local name y in the context of domain a . For fairness purposes, we address a parallel composition of processes by running one of them immediately, while the other is scheduled for later execution by placing it at the end of the run queue. When a new channel name n is created, we substitute all occurrences of n by a \fresh" name u, allocate a new entry for u in the heap and update the set of known local names as described by the [RES] rule. Local interactions are performed by the [REDIN], [REDOUT], [REDREPL], and [REDOUT*] rules. For instance, in the [REDIN] rule, the redex composed of the input process in the run queue and of the output process in the heap is reduced. Execution resumes with the continuation of the input process. The other rules are similar, mainly dealing with local communication for replicated processes. A process located in the run queue which cannot be reduced immediately is transferred into the channel queues of the heap by rules [QUEUEOUT], [QUEUEIN], and [QUEUEREPL]. It will eventually leave the heap, if local interaction becomes possible { an input/output process appears in the run queue { or if a remote emission rule is triggered.
Remote interaction is captured by the [REMXMIT] and [REMRCV] rules, which can be seen as implementing scope extrusion of calculus names between domains using the pickling/unpickling operations. If the target receiver x is remote, the repeated application of the [REMXMIT] rule will empty the communication bu er H (x) by sending several messages over the network. If the message arguments are locally created names, they must rst be pickled so they can be used by the target AM. Otherwise, these names are already in a pickled form and may be transmitted \as is". When receiving a message, an AM a must rst check if the target receiver is included in the local names known by a, as expressed by the condition unpickle(x) = (a; x ) x 2 U of the [REMRCV] rule. The argument of the message is then resolved in the context of a. If resolution yields a local name, that version will be used afterwards. Otherwise, the set of known remote names must be updated. Finally, an output process emitting on target receiver x is included at the end of the run queue. It will eventually reduce when a local interaction rule is triggered. We deem the AM to satisfy the following properties: Correctness : the AM implements correctly the dcp calculus : each set of reduction steps performed by a number of AM running in parallel corresponds to reduction steps in the base calculus. Speci c notions of bisimulation and of equivalence are necessary both to map reduction steps in the AM space to those in the calculus space, and to discard uninteresting AM states and dcp terms. 0
0
0
Fairness : a process located in the run-queue of the AM will be run after a nite number of reductions. The proof relies on the use of FIFO queues by the AM. A process located in the run queue that wishes to communicate will be transferred in the heap if reduction is not possible at once.
6 A Distributed Implementation We now present a distributed implementation of the speci cation described previously. From an implementation perspective, the k operator of the model may naturally be viewed as capturing physical distribution of domains. Thus, we implement the dcp model by a number of interpreters running concurrently on possibly di erent sites connected by a communication infrastructure. Each interpreter, written entirely in Java, executes the process terms found inside the corresponding dcp domain and is structured as follows ( gure 1): A parser, generated automatically using the jlex and cup tools, produces an abstract syntax tree from the dcp program le. This tree is used to initialize the interpreter. The input language allows the programmer to specify a number of well-known names in order for the interpreters to discover one another at system bootstrap. An execution engine implements the local reduction rules of the speci cation. Finally, a communication manager implements the remote interaction primitives. DCP PROGRAM
PARSER
ABSTRACT
EXECUTION ENGINE
u1
U u1,...,up V v1,...,vq
...
DCPORB REFERENCE
Name
MANAGER
TREE
COMMUNICATION
SYNTAX
up H
execution engine loop
v1 ... vq
R
Fig. 1. Structure of a dcp interpreter
Naming Context
Software layer
DCPORB
Application-level
managed by Name managed by DCPReference
Reference DCPBinder management
managed by DCPIdentifier managed by TCPSessionIdentifier
TcpIpProtocol
Transport
Fig. 2. Communication manager architecture
6.1 The Execution Engine One important design decision was to have the execution engine directly manipulate the high-level representation generated by the parser, instead of de ning explicitly a lower-level, bytecode-like representation produced by a separate compiler. This decision was motivated by the overall approach in the dcp experiment : we aim less
to develop a fully- edged VM, than to integrate a formal AM a la Pict with a communication infrastructure managing distribution. Thus, we were able to rapidly develop a prototype illustrating the approach. A special class called DCPMachine encapsulates the state of the interpreter, given by the structures U , V , H , and R described in the formal speci cation. These structures are initialized using data generated during the parsing phase, namely the abstract syntax tree, and the free receivers found in the current process term. For debugging purposes, a graphical frontend allows the programmer to directly visualize the state of the interpreter, to navigate through the history of past reductions, or to execute a dcp program in a step-by-step fashion. Each local reduction rule of the AM is implemented by the body of a rule method that faithfully follows the formal speci cation. Such a method returns true if the conditions to apply the rule are met. The core of execution engine is a simple loop containing calls to rule methods using an eager strategy, i.e., the rst applicable rule method is triggered. However, other scheduling policies are easily implemented by overloading the DCPMachine.run() method.
6.2 The Communication Manager jonathan : an Adaptable Middleware (review). To implement the network transparency found in our
distributed process calculus, we use a minimal framework called jonathan [2] that provides support for building highly- exible ORBs (Object Request Brokers) where objects interact transparently through remote method invocation on well-de ned interfaces. The originality of jonathan compared to traditional object platforms such as CORBA or Java RMI is to provide a core framework for building di erent types of middleware called personalities, based on the notions of binding 1 and of exible communications 2 . That exibility allowed us to easily implement the communication manager of dcp by developing a new personality directly above the TCP/IP abstractions provided by the jonathan distribution, so as to keep communications lightweight. The main jonathan abstractions include: An identi er is a generic notion of name that uniquely designates an object in a given naming context. Its semantics is naming context-speci c: distributed, persistent : : : More generally, a reference encapsulates a number of identi ers. A naming context provides name creation and management facilities. It guarantees that each of the names it controls unambiguously designates some object. A binder is a naming context that, for a given managed name, is able to create an access path towards the object designated by that name. These de nitions o er a generic and uniform view of the notion of binding, and clearly separate object identi cation from object access: In a given naming context nc, a new name for an object o is obtained by invoking the nc.export(o) method. Reference chains can then be created by exporting that name to other naming contexts. The creation of an access path to object o designated by identi er id is performed by invoking the id.bind() method which returns a ready-to-use surrogate to communicate with o. jonathan also provides a modular framework for communication protocols: a protocol object is a binder representing some network protocol. It ensures the management of session identi ers, and the creation of bindings towards session objects. A session is a logical communication channel dynamically created by a protocol object. It has higher and lower interfaces to send messages down and up a protocol stack, which may be viewed as a stack of sessions. A session identi er designates an exported session object. Its internal structure is protocolspeci c. It is typically created on the server side when an object is exported to a protocol and may be used on the client side to establish a communication channel.
Creating Local Names The communication manager is organized into three name-management layers ( gure 2). The names of the calculus are managed by the application-level layer: Name objects are controlled by a DCPORB binder which is the communication manager interface for other components of the interpreter. Lower-level layers, namely a reference management layer, and a TCP/IP transport layer are necessary This term should be understood as setting up access and communication paths between components of a distributed system. Bindings may come in a wide variety of semantics: mobile, persistent, with a QoS guarantee : : : Thus, an adaptable ORB framework should provide means to de ne bindings with various semantics, and to combine them in
exible ways. 2 With some simple architectural principles such as separating marshalling from protocol implementation, or threading from resource management, jonathan allows for instance to dynamically introduce new protocols, or to control the level of multiplexing of resources.
1
to establish communication channels for remote interactions. The creation of a fresh dcp channel name is implemented by simply creating a new instance of the LocalName class { a subclass of the aforementioned Name class.
Implementing Scope Extrusion The pickling abstract operation found in the formal speci cation can partly
be implemented using the export() method provided by the jonathan framework: a locally created name ln is exported to the current instance orb of the DCPORB binder by the call s = orb.export(ln); which returns a RemoteName surrogate s representing the pickled version of ln. That operation also exports the local name recursively to lower-level name-management layers. In particular, it creates a TCP/IP server session listening for communications on ln: any incoming message from the network will be relayed upwards in the stack of server-side sessions to the ln object for processing. At system bootstrap, dynamic interpreter discovery is made possible by using a naming service: after the parsing phase, all free receivers of the local process term are made visible to other interpreters by registering an exported version of these names with the naming service.
Implementing Remote Communication So far, a pickled name has been viewed and implemented as a
communication capability on some remote channel. Further work is needed to perform a real communication: a new binding must be created to establish a communication path to the object representing the remote channel. In the jonathan framework, such an operation is performed using the bind() method. Emission of a message hx; y i on remote channel x, where y is a pickled name represented by the RemoteName object y surrogate is implemented by: RemoteName c = (RemoteName) orb.bind((RemoteName) x); c.output(y_surrogate);
The rst call builds an access path to remote channel x. That operation recursively performs id.bind() calls on lower-level binders, where id is the binding data contained in the reference part of y surrogate 3 . Thus, a stack of client-side sessions objects is created. Once the communication path for messages is established between the two interpreters, the second call sends the reference part of y down the stack of sessions. When a message comes up the stack of sessions to the LocalName object representing a local receiver, the identi er id representing the argument is unmarshalled, and the id.bind() method is invoked. It yields a surrogate for the argument, or the argument itself if it is a local name. The state of the interpreter is then modi ed accordingly. To summarize the overall provably correct approach, the various re nements concerning naming and remote communication found during the di erent formalization steps of the dcp experiment are collected in table 1.
Design Stage Naming model Name creation Scope extrusion Inter-domain communication
Calculus
Abstract Machine Virtual Machine
Channel names
Local names (LocalName objects) Exported Names (RemoteName objects) operator Creation of a new LocalName instance. New names are automatically exported Rule a[(n) P ] export() operation on local names (n) a[P ] Marshalling / unmarshalling of exported names Rules (send) and pickle operation : Creation of a new binding : bind() operation on (receive) rules [REMXMIT] exported names and [REMRCV] Asynchronous messaging on TCP bindings
Local names Pickled Names Creation of a local name : [RES] rule pickle operation
Table 1. Re nements concerning naming and remote interaction in the dcp experiment
7 Conclusion By analyzing the di erent formalization steps from the design of a domain-based distributed programming model to its implementation, this paper makes a rst step towards programming with domains. We presented a simple programming model called dcp which extends Pict with domain and remote interaction primitives, and formalized its implementation by an AM. dcp was implemented by a distributed runtime, written in Java, seamlessly integrated with the jonathan ORB which provides support for distribution. 3
Such information is possibly obtained by contacting the naming service.
dcp domains are not endowed with any speci c behavior which could include the creation of new domains, the ltering of incoming or outgoing messages, etc. To capture such situations of distributed mobile programming, a more powerful calculus is required where the dcp domain construct a[P ] could be replaced with a more general primitive P [Q] where process P controls the behavior of Q. Such a calculus is currently under de nition. Future work also includes examining scalability issues arising in a tree-structured domain topology, more adapted to wide-area network programming, and taking into account communications security, and process mobility. dcp is one of the rst process calculi both to formalize its implementation in terms of an AM in a distributed setting, and to be implemented on top of an ORB. By making remote interaction constructs as primitive, we allow the model to re ect partly the form an actual provably correct distributed implementation would take, using available distributed system technology. We also make it possible to achieve compatibility with existing de facto standards in the area like CORBA or Java RMI { an important prospect for programming distributed applications in a real, heterogeneous setting.
Acknowledgments We wish to thank Jean-Bernard Stefani and Sacha Krakowiak for their many valuable comments on an earlier version of the paper.
References 1. G. Berry and G. Boudol. The Chemical Abstract Machine. Theoretical Computer Science, 96:217{248, 1992. 2. B. Dumant, F. Dang Tran, F. Horn, and J.-B. Stefani. Jonathan : an Open Distributed Platform in Java. In Proceedings of the IFIP International Conference on Middleware, Lake District, UK, September 1998. 3. C. Fournet and G. Gonthier. The Re exive Chemical Abstract Machine and the Join-Calculus. In Proceedings of the 23rd ACM Symposium on Principles of Programming Languages, pages 372{385, St. Petersburg Beach, Florida, January 1996. 4. F. Germain, E. Najm, and J.-B. Stefani. Elements of an Object-Based Model for Distributed and Mobile Computation. In Proceedings of the Fourth International Conference on Formal Methods for Open Object-Based Distributed Systems, Palo Alto, California, September 2000. 5. M. Lacoste and J.-B. Stefani. DCP: Towards Distributed Programming with Domains. Not published to-date. 6. L. Lopes. On the Design and Implementation of a Virtual Machine for Process Calculi. PhD thesis, Departamento de Ci^encia de Computadores, Facultade de Ci^encias da Universidade do Porto, October 1999. 7. P. Sewell, P. Wojciechowski, and B. Pierce. Location-Independent Communication for Mobile Agents: a Two-Level Architecture. Technical Report 462, Computer Laboratory, University of Cambridge, 1999. 8. D. Turner. The Polymorphic Pi-calculus: Theory and Implementation. PhD thesis, University of Edinburgh, 1996.
Appendix Syntax:
Evaluation contexts:
C ::= nil (n)C M a[P ] (C C ) P ::= (P P ) (n)P 0 x?(~y):P x! y~ if u = v then P else Q M ::= x; y~ j
j
j
j
j
j
j
k
j
j
h i
j
h
j
P
E1 ::= F ::= E2 ::=
j
j
j
(n) E1 (E1 P ) a[ ] (n) F (F C ) (n) E2 (E2 P ) a[ ] j
j
j
k
j
j
j
j
j
E1 x?(~y):E1
j
i
Reduction relation:
Structural equivalence: P a[(n) P ] ((n) P Q) ((n) C D)
j
k
P Q C D
)
)
P P (n) a[P ] (n)(P Q) if n (n)(C D) if n
(if-true) (if-false)
j
j
62
k
E1 (P ) E1 (Q) F (C ) F (D)
62
Q) fn(D)
fn(
u=v u=v 6
) )
if if
u = v then P else Q u = v then P else Q
m?(~u):P m! v~
(com)
j
(send) m = dn(P ) (receive) m dn(P )
a[P m! v~ ] m; v~ a[P ]
2
)
2
) h
P C
! !
Q D
Fig. 3. Syntax and semantics of the dcp calculus
) )
j
h i
i k
! !
!
P Q
v~=u~ P
h i ! f
g
a[P ] m; v~ a[P m! v~ ]
E2 (P ) E2 (Q) F (C ) F (D) !
! !
k h
j
i
h i
Syntactic categories:
Notations:
m; n; u; v : : : Name Channel name a; b; : : : DName Machine name P; Q; : : : Proc Process Msg = Name x Name Message
A
Set of nite maps from set A to set B . An element is f = a1 b1 ; : : : ; ak bk f a b Extension of f with the binding a b A Set of nite collections of elements of A Queue(A) Set of queues of elements of A. An element is a1 :: : : : :: an Empty queue
2
2
f
2
@
f
2
Name transformation: pickle unpickle
6
6
_
7!
State of the AM:
a; x)) = (a; x) x)) = x x = y pickle(a; x) = pickle(b; y) unpickle(x) = unpickle(y )
U V H R S
!
6
)
7!
7!
!
)
7!
g
: DName x Name Name : Name DName x Name
LNames = Name Local names RNames = Name Remote names Heap = Name Queue(Proc) Heap RQueue = Queue(Proc) Run queue AMachine = DName x LNames x RNames x Heap x RQueue AM state N Network = AMachine x Msg Networks
unpickle(pickle( pickle(unpickle(
a=b x=y
B
7!
6
6
2
2
2
7!
2
2
2
Reduction rules: a; U; V; H; (P Q) :: R
[PRL]
j
!
a; U; V; H; P :: R :: Q
[RES]
u = U V U0 = U u a; U; V; H; (n P ) :: R a; U 0 ; V; H u
[REDIN]
x U H (x) = x! y~ :: wr y~ U V a; U; V; H; x?(~z):P :: R a; U; V; H x wr ; y~=z~ P :: R
[REDOUT]
x U H (x) = x?(~z):Q :: rd y~ U V a; U; V; H; x! y~ :: R a; U; V; H x rd ; R :: y~=z~ Q
[REDREPL]
x U H (x) = x! y~ :: wr y~ U V a; U; V; H; x?(~z):P :: R a; U; V; H x wr ; x?(~z):P :: R :: y~=z~ P
[REDOUT*]
x U H (x) = x?(~z):Q :: rd y~ U V a; U; V; H; x! y~ :: R a; U; V; H x rd :: x?(~z):Q ; R :: y~=z~ Q
[QUEUEOUT]
x U V H (x) = wr y~ U V a; U; V; H; x! y~ :: R a; U; V; H x wr :: x! y~ ; R
[QUEUEIN]
x U H (x) = rd a; U; V; H; x?(~z):P :: R a; U; V; H x
2
[
[ f
!
f
2
g
; u=n P :: R
7! g f
h i
2
!
f
[
7!
2
g f
2
h i
!
f
2
7!
[
2
f
7!
2
!
f
f
g
[
g
f
g
[
7!
h ig
2
!
g
g
[
h i
f
2
f
!
2
g
h i
2
h i
g
[
7!
!
g
f
7!
rd :: x?(~z):P ; R g
[REMXMIT]
x U H (x) = rd a; U; V; H; x?(~z):P :: R a; U; V; H x rd :: x?(~z):P ; R 8 < x V H (x) = x! y1 ; : : : ; ys :: wr pickle(a; yi ); 1 i s : ifif yyii VU zzii = = yi ; 1 i s a; U; V; H; R a; U; V; H x wr ; R x; z~
[REMRCV]
x) =(a; x0 ) x0 U unpickle(yi ) = (a; yi0 ) yi0 U zi = yi0 Ti = for 1 i s ifif unpickle (yi ) = (b; ) b = a zi = yi Ti = yi V 0 = V Ssi=1 Ti x; y1 ; : : : ; ys a; U; V; H; R a; U; V 0 ; H v V 0 V v ; R :: x0 ! z~
[QUEUEREPL]
2
!
2
f
h
!
f
unpickle(
h
g
i
2
2
7!
7!
g
k
h
i
2
2
;
6
f
g
[
i
k
!
f8
2
Fig. 4. The dcp abstract machine : main de nitions
n
7! g
h i
g
