Message or Object Origin and Future of ConcurrentMobile

Message or Object? -- Origin and Future of Concurrent/Mobile Objects -Akinori Yonezawa University of Tokyo Invited Talk at FOOL 7 (Foundations of Object. Oriented Languages) in Boston, January. 22, 2000

Modular Actor Formalism for AI • Manifesto/slogan paper by Carl Hewitt et al. (MIT) appeared in Proc. IJCAI’ 73 (Stanford, Aug. 1973) – Procedural Embedding of Knowledge/Data (Minsky School of AI) – Message Passing Paradigm procedural entities get activated by receiving messages. => basic idea of objects – Introducing Inherent Parallelism message transmissions can take place concurrently. => intuitive idea of concurrent objects/actors 2

“Actors” or “Concurrent Objects (COs)” • “Actors” refer to Hewitt & Agha’s model – Hewitt&Baker’s IFIP paper[77]. – Agha’s Actor book[86], established & functional flavored model. mail address, behavior replacement, transition system semantics, … • “COs” refer to Yonezawa’s model – my thesis[77], OOPSLA paper[86], and ABCL book[90]. – thesis is supervised by C. Hewitt and entitled: • “Specification and Verification Techniques for Parall. Moel Programs Based on Message-Passing Semantics, ” (MIT/LCS/TR-191, 1977) 3

my CO Computation Model [1977] • Notion of Concurrent Objects – Introducing local state notions into Actor framework formalism (somewhat against the supervisor’s advice). • Contrasting to Agha&Hewitt’s actor model, which has strong functional flavors, avoiding state notions. – Considering how to optimally distribute (partition ) system’s function over messages and concurrent objects. 4

Concurrent Objects (COs) - 1 -- Computation Model - • a CO has – – – globally unique identity/name. protected updateable local memory. a set of procedures attached to the memory. procedure gets activated by receiving a specified message. a single FIFO queue of arrived messages. autonomous thread(s) of control. non-state-updating threads can be concurrent. 5

Concurrent Objects (COs) - 2 -- Computation Model - • In a CO, – memory-updating procedures are activated one at a time with corresponding message arrival order. – its local state can be defined at the time of message arrival, owing to its single FIFO message queue. • a CO can – send messages to the COs whose ids it knows about at the time of sending. -- point-to-point communication – remember and forget the names of other COs. -- dynamic topology for message transmission – dynamically create COs. 6

What to be Transmitted to a Concurrent Object? -- Messages or Objects— • message tags/headers, values, CO-ids, … • COs should be allowed to be transmitted! – origin of mobile/migratory objects – see “Cambridge Post Office” example – my modeling Post Office suggests “Ambient. ” • COs in motion can receive messages 7

Specifying Behavior of COs - Local State Approach • Use of “Conceptual Representations” – for describing states of individual COs. • Separation of CO’s state and its identity – for describing mutable COs. • Specifications of interactions of COs – “event specifications” – “task specifications” for collective behavior by of Cos. 8

Formal Specification Language • Describing local states of a CO – by conceptual representations which use • conceptual name, • abstract { sequences, records, sets } e. g. , (Queue [h !tl ]), (Mail. Collector {!letter}) (Post. Office {c 1, c 2, c 3}) (c 2 is-a (Counter q 2)) (c 3 is-a (Mail. Box {!m})) 9

Formal Specification Lang. (cont. ) • Describing interactions of – a CO and a message – a CO and a CO • Describing caused events/effects – changes in local states of COs – creation of new COs – caused message transmissions • First order language on event ordering 10

Specification of Interactions • “Interaction” means – a message arrives at a CO. – COs collide. • Interactions are often called “Events. ” 11

Conceptual Representations -- examples -(Queue [9 2 4]) -- a queue with three elements (Queue [8 !r]) – a queue with first element being 8 (Queue [!r 8]) – a queue with last element being 8 (Cons-cell (car: 1)(cdr: 7)) – a Lisp cons-cell (Semaphor (counter: 1)(waiting-processes: [!wps])) – a semaphor with processes suspended (Collection {… 9 … 7 …}) – a collection containing 9 and 7 12

Separation of Identity and State • a CO has mutable states and is shared and referenced to by more than one CO. – formal specifications need to describe CO’s state and identity separately!! – e. g. , (q is-a (Queue [9 11 7])) in Situation-1, (q is-a (Queue [9 11 7 13])) in Situation-2 13

Notations for Event/Interaction Specifications > ** Assertions in the next-cond clause specify the local state of each CO (that is involved in the event) at the time the CO receives the next message (or at the time of CO creation). 14

Formal Specification of a Queue ; ; fresh queue sent > > ; ; fresh queue is empty ; ; enqueuing ; ; a is put at the end ; ; front elmnt is a ; ; a is sent > ; ; the front elmnt deleted 15

Pure/Functional Queue > ; ; a fresh queue created with a at its end. ; ; error!! >) ; ; original queue intact (Case-2: ; ; when a is at front, ; ; a is replied. ) > 16 ; ; a fresh queue created with a deleted

Interaction between Vender and Customer Vendor’s state -- (VENDER (bills: {…}) (goods: {…})) Customer’s state -- (CUSTOMER (bills: {…}) (belongings: {…})) (V is-a -- no event caused > 17

Semaphor with P/V-ops Semaphor’s state -- (SEMAPHOR (counter: N) (waiting-q: [!ps]) ) (Case-2: ; ; when counter is positive, 0) > ; ; P is allowed to enter critical sec )> . . . ) (Case-2: ; ; when counter is positive, )> 18

A Good Convincing Example • Advisor suggested me to find a Good example. – intuitively clear, yet reasonably complex – high internal concurrency • Cambridge Post Office (CPO) is chosen: – a number of customers visit a post office. – each customer comes to a post office counter if necessary. – buys stamps or do registration – puts stamps on envelops – put them into the mail box, and leave the post office – mail collectors come to collects mail … 19

Cambridge　Post　Office 　　　　　　　 counter-section mailbox door 20

How to Model CPO with COs • Let door CO represents the building of Post Office. • customer’s entering/exiting the PO is modeled by transmission of customer CO to/from the door CO. • the state of Post Office is represented by that of the door CO. 21

State of the PO (door CO) • We define the state of the PO at the time of message arrival by – a set of all customers inside the post office, – a set of all collectors inside the post office, and – a set of all mail inside the post office. (POST-OFFICE (mail: {…})(customers: {…})(collectors: {…}) (door is-a (POST-OFFICE … (customers: {!cs})(collectors: {!cls}))) 22

Messages/COs sent to door CO Four kinds: (customer-entering: ) (customer-exiting: ) (collector-entering: ) (collector-exiting: ) 23

States of Customer and Collector (CUSTOMER (letters: {…})(#-of-stamps-needed: n)) (COLLECTOR　(collected-mail: {…})) 24

Interactions between the door CO and a customer CO See next slide. 25

> > 26

Interactions between the door CO and a collector CO similar to the previous side 27

States of Mail Box CO / Interactions at Mail Box CO (MAIL-BOX (posted-mail: {!m})) See next slide for interaction specs. 28

> > 29

Ambient Calculi -- L. Cardelli & A. Gordon -- • a great work of formalizing mobile and concurrent objects!! 30

Is the PO an Ambient? • PO building can be viewed as an ambient of Cardelli & Gordon’s calculus. 　　 po[MAILBOX | COUNTER | …CUSTOMERi…] | 　 in po CUSTOMERj po[MAILBOX | COUNTER | … out po I-CUSTOMERm…] 31

Task Specifications [1977] • Specifications of overall functions of a distributed system (e. g. , OS, the Post Office) • Task spec. needs to be derived/verified through specs of individual CO’s behavior and their interactions. 32

Task Spec. 1 • Customer eventually leaves the PO. • When the customer leaves, he carries no letter and needs no stamp. > 33

Task Spec. 2 • Collectors eventually leaves the PO. • When a collector leaves, he always carries the letters that he carried in. > 34

Task Spec. 3 • Let {!m} be a set of letters brought into the PO by a customer C. If there is a collector CL who enters the PO after the customer C leaves, then there exits a collector who brings the set {!m} of letters out of the PO to the street. a more formal version is written in our spec. language with the ordering of the events specified. (see next slide) 35

For an event Ec-enter = [door <= (customer-entering: C)] where (C is-a (CUSTOMER (letters: {!m})(#-of-stamps-needed: N)))), if there exits an event Ecl-enter = [door <= (collector-entering: CL)] such that Ec-enter --> Ec-exit -arr->door Ecl-enter where Ec-exit = [door <= (customer-exiting: C)], then there must exit an event Ecll-street = [street <= CLL] such that (CLL is-a (COLLECTOR (collected-mail: {…!m…}))). -arr->door : order of message arrival at door CO 36

Assumptions of No Implicit Interactions for verifying task specs • Assumption-1: customers and collectors do not receive any message except those explicitly stated in the event specifications. • Assumption-2: the counter and the mail box interact with only the customers and collectors which are in the PO. 37

Comments on Ambient Calculi • a great series of work!! • what kinds of properties to describe and prove? – The above “task specifications” can be stated? • in case where local states of ambients need to be referred to. • Eventuality with state descriptions? – “Assumptions of No Implicit Interactions” are taken care of in Ambient Caluculi. – What about security proof of implementation code? 38

I am now working on Autonomous Mobile Objects • Used to think about eliminating artificial dichotomy of objects and messages. – messages can be objects. – object can be messages. – both can move and be transmitted and persistent. • Now working on AMOs (Autonomous Mobile Objects), which move on their initiative. 39

Our Mobile Object Languages • Java. GO • Mobile. ML 40

Java. GO – Allows to put go statements anywhere in Java code – The code area (including go) specified by undock-construct migrates to , and its continuation stays and gets activated asynchronously. undock{go(“//hal: : 2001/Java. Go. Executor”); System. out. println(“nice to meet you”); } System. out. println(“bye!”); Cf. A Simple Extension of Java Language for Controllable Transparent Migration and its Portable Implementation (T. Sekiguchi et al. Coordination'99, LNCS no. 1594) 41

Java. GO (cont. ) • The language system is available: http: //www. yl. is. s. u-tokyo. ac. jp/amo/ • Using the language, we are implementing network games a la “Pokemon” and “Magic, the Gathering. ” 42

Mobile. ML – Has an ML-style type system. – Code migrates to a program context in other site. context k withhole X = let name = “HAL” in X; ; ; at site “hal: : 2001” – Allows to put go expressions anywhere in ML code. – An agent expression agent (e) containing go specifies the region which migrates to , and variables may be dynamically bound at . agent(go “//hal: : 2001/k”; print_string(“Hello, ”^`name)); print_string (“Bye!”); 43

Mobile. ML (cont. ) – Based on A Typed Context Calculus (M. Hashimoto and A. Ohori, to appear in TCS) A Calculus with Code Mobility (T. Sekiguchi and A. Yonezawa, FMOODS’ 97) 44