Active Objects INF4140 16.11.11 Lecture 12 INF4140 (16.11.11) - - PowerPoint PPT Presentation

Active Objects

INF4140

16.11.11

Lecture 12

INF4140 (16.11.11) Active Objects Lecture 12 1 / 27

Aims for this lecture

About distributed object-oriented systems and Introduction to Creol Consider the combination of OO, concurrency, and distribution Understanding active objects

interacting by asynchronous method calls

A short introduction into (a variant of) Creol using small example programs Note: Inheritance and dynamic object creation not considered here.

INF4140 (16.11.11) Active Objects Lecture 12 2 / 27

Open Distributed Systems

Consider systems of communicating software units Distribution: geographically spread components

Networks may be asynchronous and unstable Component availability may vary over time

Evolution: systems change at runtime

New requirements / bug fixes Changing environments Mars Rovers reprogrammed 11 times since landing on Mars!

ODS dominate critical infrastructure in society: bank systems, air traffic control, etc. ODS: complex, error prone, and poorly understood

Network

INF4140 (16.11.11) Active Objects Lecture 12 3 / 27

Challenges with OO languages for modern systems

Modern systems are often large and complex, with distributed, autonomous units connected through different kinds of networks. OO + distribution efficient interaction (passive/active waiting), OO + concurrency synchronization, blocking, deadlock OO + asynchronous communication messages on top of OO or method-based communication? problems with RPC/RMI OO + openness reprogramming at runtime OO + scalability management of large systems

INF4140 (16.11.11) Active Objects Lecture 12 4 / 27

Active and Passive Objects

Passive objects Execute their methods in the caller’s thread of control (e.g., Java) In multithreaded applications, must take care of synchronization

Shared variable interference for non-synchronized methods

If two objects call the same object, race condition may occur Active (or concurrent) objects Execute their methods in their own thread of control (e.g., Actors) Communication is asynchronous Call and return are decoupled (future variables) Cooperative multitasking, specified using schedulers

INF4140 (16.11.11) Active Objects Lecture 12 5 / 27

Motivation and Desires behind Creol

Integration of OO + distribution + concurrency + openness integration of requirement and guarantee specifications simplicity of semantics, and formal analysis powerful tools based on the semantics: prototyping, simulation, verification and validation tools scalability ensured by compositionality and abstraction mechanisms dynamic reconfiguration/reprogramming with incremental reasoning support

INF4140 (16.11.11) Active Objects Lecture 12 6 / 27

Creol: A Concurrent Object Model

All objects are active (or concurrent), but may receive requests

Need easy way to combine active and passive/reactive behavior

We don’t always know how objects are implemented

Separate specification (interface) from implementation (class) Object variables are typed by interface, not by class

No assumptions about the (network) environment

Communication may be unordered Communication may be delayed Execution should adapt to possible delays in the environment

Synchronization decided by the caller

Method invocations may be synchronous or asynchronous

Systems evolve at runtime

Support for dynamic reprogramming

INF4140 (16.11.11) Active Objects Lecture 12 7 / 27

Interfaces as types

Object variables (pointers) are typed by interfaces (other variables are typed by data types) Mutual dependency: An interface may require a cointerface

Only objects of cointerface type may call declared methods Explicit keyword caller (identity of calling object) Supports callbacks to the caller through the cointerface

All object interaction is controlled by interfaces

No explicit hiding needed at the class level Interfaces provide behavioral specifications A class may implement a number of interfaces

Type safety: no “method not understood” errors

INF4140 (16.11.11) Active Objects Lecture 12 8 / 27

Interfaces

Declares a set of method signatures With cointerface requirement

interface I inherits I begin with J MtdSig // cointerface J end

Method signatures (MtdSig) of the form:

• p m ✭in x : I out y : I✮

method mame m with in-parameters x and out-parameters y Parameter types may also range over data types (Bool, Int,

• String. . . )

INF4140 (16.11.11) Active Objects Lecture 12 9 / 27

Interfaces: Example

Consider the mini bank example from last week We have ❈❧✐❡♥t, ❆❚▼, and ❈❡♥tr❛❧❇❛♥❦ objects Clients may support the following interface:

interface ❈❧✐❡♥t begin with ❆❚▼

• p ♣✐♥✭out ♣ ✿ ■♥t✮
• p ❛♠♦✉♥t✭out ❛ ✿ ■♥t✮

end

• nly ❆❚▼ objects may call the ♣✐♥ and ❛♠♦✉♥t methods

INF4140 (16.11.11) Active Objects Lecture 12 10 / 27

Interfaces: Example (cont.)

❆❚▼ and ❈❡♥tr❛❧❇❛♥❦ interfaces:

interface ❆❚▼ begin with ❈❧✐❡♥t

• p ✇✐t❤❞r❛✇✭in ♥❛♠❡ ✿ ❙tr✐♥❣ out r❡s✉❧t ✿ ❇♦♦❧✮

end interface ❈❡♥tr❛❧❇❛♥❦ begin with ❆❚▼

• p r❡q✉❡st✭in ♥❛♠❡ ✿ ❙tr✐♥❣✱ ♣✐♥ ✿ ■♥t✱ ❛♠♦✉♥t ✿ ■♥t
• ut r❡s✉❧t ✿ ❇♦♦❧✮

end

INF4140 (16.11.11) Active Objects Lecture 12 11 / 27

Asynchronous Communication Model

• 1
• 2

Object o1 calls some method on object o2 In o2: Arbitrary delay after invocation arrival and method startup In o1: Arbitrary delay after completion arrival and reading the return

INF4140 (16.11.11) Active Objects Lecture 12 12 / 27

Main ideas of Creol: Programming perspective

Main ideas: Asynchronous communication Avoid undesired inactivity

Other processes may execute while some process waits for a reply

Combine active and reactive behavior In the language, this is achieved by statements for asynchronous method calls and processor release Note: Relase points enable interleaving of active and reactive code Note: No need for signaling / notification

INF4140 (16.11.11) Active Objects Lecture 12 13 / 27

Execution inside a Creol Object

Concurrent objects encapsulate a processor Execution in objects should adapt to environment delays At most one active process at a time Implicit scheduling between internal processes inside an object

Object STATE

INF4140 (16.11.11) Active Objects Lecture 12 14 / 27

Internal Processes in Concurrent Objects

Process (method activation): code + local variable bindings (local state) Object: state + active process + suspended processes Asynchronous invocation: t!o.m(In)

The label t identifies the call

Reading the result: t?(Out) Processor release points

Declared by await statements: await guard Guards can be

t? Boolean condition and also method call

If a guard evaluates to false the active process is suspended If no process is active, any suspended process may be activated if its guard evaluates to true.

INF4140 (16.11.11) Active Objects Lecture 12 15 / 27

Statements for object communication

Objects communicate through method invocations only Different ways to invoke a method m Decided by caller — not at method declaration site Guarded invocation: t!o.m(In); . . . ; await t?; t?(Out) Label free abbreviations for standard patterns:

• .m(In; Out) = t!o.m(In); t?(Out) — synchronous call

await o.m(In; Out) = t!o.m(In); await t?; t?(Out) !o.m(In) — no reply needed

Internal calls: m(In; Out), t!m(In), !m(In) Internal calls may also be asynchronous/guarded

INF4140 (16.11.11) Active Objects Lecture 12 16 / 27

Creol syntax

Syntactic categories. Definitions. t ✐♥ Label g ✐♥ Guard p ✐♥ MtdCall S ✐♥ ComList s ✐♥ Com x ✐♥ VarList e ✐♥ ExprList m ✐♥ Mtd

• ✐♥ ObjExpr

b ✐♥ BoolExpr g ::= φ | t? | g1 ∧ g2 p ::= o.m | m S ::= s | s; S s ::= skip | begin S end | S1S2 | x := e | x := new classname(e) | if b then S1 else S2 end | while b do S end | !p(e) | t!p(e) | t?(x) | p(e; x) | await g | await p(e; x) | release Omit the functional language for expressions e here: this, caller, strings, integers, lists, sets, maps, etc

INF4140 (16.11.11) Active Objects Lecture 12 17 / 27

Example: ❈❡♥tr❛❧❇❛♥❦ implementation

class ❇❛♥❦ implements ❈❡♥tr❛❧❇❛♥❦ begin var ♣✐♥ ✲✲ ♣✐♥ ❝♦❞❡s✱ ✐♥❞❡①❡❞ ❜② ♥❛♠❡ var ❜❛❧ ✲✲ ❜❛❧❛♥❝❡s✱ ✐♥❞❡①❡❞ ❜② ♥❛♠❡ with ❆❚▼

• p r❡q✉❡st✭in ♥❛♠❡ ✿ ❙tr✐♥❣✱ ♣✐♥ ✿ ■♥t✱ ❛♠♦✉♥t ✿ ■♥t
• ut r❡s✉❧t ✿ ❇♦♦❧✮ ❂❂

if ✭♣✐♥❬♥❛♠❡❪ ❂ ♣✐♥ ✫✫ ❜❛❧❬♥❛♠❡❪ ❃❂ ❛♠♦✉♥t✮ then r❡s✉❧t ✿❂ true else r❡s✉❧t ✿❂ false end end

INF4140 (16.11.11) Active Objects Lecture 12 18 / 27

Example: ❆❚▼ implementation

class ❆❚▼✭❜❛♥❦ ✿ ❈❡♥tr❛❧❇❛♥❦✮ implements ❆❚▼ begin with ❈❧✐❡♥t

• p ✇✐t❤❞r❛✇✭in ♥❛♠❡ ✿ ❙tr✐♥❣ out r❡s✉❧t ✿ ❇♦♦❧✮ ❂❂

var ❛♠♦✉♥t ✿ ■♥t✱ ♣✐♥ ✿ ■♥t❀ ❝❛❧❧❡r✳♣✐♥✭❀♣✐♥✮❀ ❝❛❧❧❡r✳❛♠♦✉♥t✭❀❛♠♦✉♥t✮ await ❜❛♥❦✳r❡q✉❡st✭♥❛♠❡✱ ♣✐♥✱ ❛♠♦✉♥t❀ r❡s✉❧t✮ end

method calls ❝❛❧❧❡r✳♣✐♥✭✳✳✳✮ and ❝❛❧❧❡r✳❛♠♦✉♥t✭✳✳✳✮ are type safe by cointerface requirements await statement: passive waiting for reply from ❈❡♥tr❛❧❇❛♥❦

INF4140 (16.11.11) Active Objects Lecture 12 19 / 27

Example: ❈❧✐❡♥t implementation

Optimistic client:

class P❡rs♦♥✭❛t♠ ✿ ❆❚▼✮ implements ❈❧✐❡♥t begin var ♥❛♠❡ ✿ ❙tr✐♥❣✱ ♣✐♥ ✿ ■♥t❀

• p r✉♥ ❂❂ s✉❝❝❡ss ✿ ❇♦♦❧❀

await ❛t♠✳✇✐t❤❞r❛✇✭♥❛♠❡❀s✉❝❝❡ss✮❀ if ✭s✉❝❝❡ss ❂❂ false✮ then ✦r✉♥ end with ❆❚▼

• p ♣✐♥✭out ♣ ✿ ■♥t✮ ❂❂ ♣ ✿❂ ♣✐♥
• p ❛♠♦✉♥t✭out ❛ ✿ ■♥t✮ ❂❂ ❛ ✿❂ ✶✵✵✵

end

Assuming communication with a fixed ATM

INF4140 (16.11.11) Active Objects Lecture 12 20 / 27

Main ideas of Creol: Programming perspective

concurrent objects (each with its own virtual processor) a notion of asynchronous methods calls, avoids blocking, using a notion of processor release high level process control

no explicit signaling/notification busy waiting avoided!

OO qualities: subclassing, multiple inheritance, late binding + mechanisms for static binding, multiple interfacing

• penness by a notion of dynamic reconfiguration/reprogramming

abstraction by behavioral interfaces type safe call-backs due to cointerfaces

INF4140 (16.11.11) Active Objects Lecture 12 21 / 27

Example: Buffer

interface ❇✉❢❢❡r begin with Pr♦❞✉❝❡r op ♣✉t✭in ① ✿ ■♥t✮ with ❈♦♥s✉♠❡r op ❣❡t✭out ① ✿ ■♥t✮ end class ❖♥❡❙❧♦t❇✉❢❢❡r implements ❇✉❢❢❡r begin var ✈❛❧✉❡ ✿ ■♥t✱ ❢✉❧❧ ✿ ❇♦♦❧❀

• p ✐♥✐t ❂❂ ❢✉❧❧ ✿❂ false

with Pr♦❞✉❝❡r

• p ♣✉t✭in ① ✿ ■♥t✮ ❂❂ await ¬❢✉❧❧❀ ✈❛❧✉❡ ✿❂ ①❀ ❢✉❧❧ ✿❂ true

with ❈♦♥s✉♠❡r

• p ❣❡t✭out ① ✿ ■♥t✮ ❂❂ await ❢✉❧❧❀ ① ✿❂ ✈❛❧✉❡❀ ❢✉❧❧ ✿❂ false

end

✐♥✐t: initialization code executed at object creation

INF4140 (16.11.11) Active Objects Lecture 12 22 / 27

Example: Buffer (cont.)

Illustrating alternation between active and reactive behavior

class ❈♦♥s✉♠❡r✭❜✉❢✿ ❇✉❢❢❡r✮ implements ❈♦♥s✉♠❡r begin var s✉♠ ✿ ■♥t ✿❂ ✵❀

• p r✉♥ ❂❂ var ❥ ✿ ■♥t❀

while true do await ❜✉❢✳❣❡t✭❀❥✮❀ s✉♠ ✿❂ s✉♠ ✰ ❥ end with ❆♥② op ❣❡t❙✉♠✭out s ✿ ■♥t✮ ❂❂ s ✿❂ s✉♠ end

Call to ❜✉❢✳❣❡t:

Asynchronous await: processor release Incoming calls to ❣❡t❙✉♠ can be served while waiting for reply from ❜✉❢

Interface ❆♥②: supertype of all interfaces

Any object can call ❣❡t❙✉♠

INF4140 (16.11.11) Active Objects Lecture 12 23 / 27

Readers/Writers example (Simple implementation)

interface RW begin with RWClient

• p OR — open read
• p OW — open write
• p CR — close read
• p CW — close write

end class RW implements RW begin var r: Int:=0; var w: Int:=0; with RWClient

• p OR == await w=0; r:= r+1
• p OW == await w=0 and r=0; w:= w+1
• p CR == r:= r-1
• p CW == w:= w-1

end

Note: A client may do asynchronous calls to OR/OW and synchronous calls to CR/CW.

INF4140 (16.11.11) Active Objects Lecture 12 24 / 27

Readers/Writers example (version 2)

class ❘❲✭❞❜ ✿ ❉❛t❛❇❛s❡✮ implements ❘❲ begin var r❡❛❞❡rs ✿ ❙❡t❬❘❡❛❞❡r❪ ✿❂ ∅✱ ✇r✐t❡r ✿ ❲r✐t❡r ✿❂ null✱ ♣r ✿ ■♥t ✿❂ ✵❀ // number of pending calls to db.read with ❘❡❛❞❡r

• p ❖❘ ❂❂ await ✇r✐t❡r ❂ null❀ r❡❛❞❡rs ✿❂ r❡❛❞❡rs ∪ ❝❛❧❧❡r
• p ❈❘ ❂❂ r❡❛❞❡rs ✿❂ r❡❛❞❡rs \ ❝❛❧❧❡r
• p r❡❛❞✭in ❦❡② ✿ ■♥t out r❡s✉❧t ✿ ■♥t✮ ❂❂

await ❝❛❧❧❡r ∈ r❡❛❞❡rs❀ ♣r ✿❂ ♣r ✰ ✶❀ await ❞❜✳r❡❛❞✭❦❡②❀r❡s✉❧t✮❀ ♣r ✿❂ ♣r ✲ ✶❀ with ❲r✐t❡r

• p ❖❲ ❂❂ await ✭✇r✐t❡r ❂ null ✫✫ r❡❛❞❡rs ❂ ∅ ✫✫ ♣r ❂ ✵✮❀

✇r✐t❡r ✿❂ ❝❛❧❧❡r

• p ❈❲ ❂❂ await ❝❛❧❧❡r ❂ ✇r✐t❡r❀ ✇r✐t❡r ✿❂ null
• p ✇r✐t❡✭in ❦❡② ✿ ■♥t✱ ✈❛❧✉❡ ✿ ■♥t✮ ❂❂

await ❝❛❧❧❡r ❂ ✇r✐t❡r❀ ❞❜✳✇r✐t❡✭❦❡②✱✈❛❧✉❡✮❀ end

INF4140 (16.11.11) Active Objects Lecture 12 25 / 27

RW example, remarks (version 2)

r❡❛❞ and ✇r✐t❡ operations on database may be declared with cointerface ❘❲ Weaker assumptions about ❘❡❛❞❡r and ❲r✐t❡r behavior than in the first version

Here we actually check that only registered readers/writers do read/write operations on the database

The database is assumed to store integer values indexed by ❦❡② Counting the number of pending calls to db.read (variable ♣r) A reader may call ❈❘ before all r❡❛❞ invocations are completed For writing activity, we know that there are no pending calls to ❞❜✳✇r✐t❡ when ✇r✐t❡r is null. Why? The solution is unfair: writers may starve Still, after completing ❖❲, we assume that writers will eventually call ❈❲. Correspondingly for readers

INF4140 (16.11.11) Active Objects Lecture 12 26 / 27

Summary: Active Objects

Passive objects usually execute their methods in the thread of control of the caller (Java) In multithreaded applications, we must take care of proper synchronisation Active objects execute their methods in their own thread of control Communication is asynchronous synchronous communication possible by means of asynchronous communication primitives Call and return are decoupled by the use of labels Usually, active objects use cooperative multitasking. Cooperative multitasking is specified using schedulers. Our scheduler will just randomly pick a next process.

INF4140 (16.11.11) Active Objects Lecture 12 27 / 27