Asynchronous Distributed Components Concurrency and Determinacy Denis CAROMEL

Asynchronous Distributed Components: Concurrency and Determinacy Denis CAROMEL I. Ludovic HENRIO Context: Distributed Components and Active Objects II. Asynchronous Distributed Components III. Deterministic Distributed Components TCS 2006 - 23/08/2006

Content I. Context: Distributed Components and Active Objects II. Asynchronous Distributed Components III. Deterministic Distributed Components

Context l l l Fractal: a component model specification An implementation in Pro. Active - Hierarchical composition - Asynchronous, distributed components - Non-functional aspects and lifecycle Formal aspects - Kell calculus component control (passivation) - ASP components Communication, hierarchy and deterministic components

ASP Calculus Summary An Asynchronous Object Calculus: - Structured asynchronous activities - Communications are asynchronous method calls with futures (promised replies) - Futures data-driven synchronization ASP Confluence and Determinacy Future updates can occur at any time Execution characterized by the order of request senders Determinacy of programs communicating over trees, …

Services in ASP l Pending requests are stored in a queue. l Request service in ASP: Serve(foo, bar) serves the oldest request on the method foo or bar. l Potential Service: an approximation of the set of services (set of methods M) that can appear in the Serve(M) instructions that an activity a may perform in the future. = {{foo, bar}, {gee}}

Deterministic Object Networks g b delta. gee(a) bar gee d {foo, bar} {bar, gee} , {foo} gee bar DON(P): delta. bar(a)

Static DON a d f {foo, bar} {gee}, {f, g} , {gee} {foo, bar} {f, g}, {gee} g g foo g f {foo, bar} {foo}, {bar} , {gee} bar b f g e {bar} {gee}, , {gee} {f, g} The difficulty is to statically gee {gee}, {f, g} approximate activities, method calls and potential services

Content I. Context: Distributed Components and Active Objects II. Asynchronous Distributed Components III. Deterministic Distributed Components

Primitive Components Requests Server Interfaces A Primitive Component Requests Client Interfaces Method names Fields

Hierarchical Composition Input interfaces Primitive component Export PC Binding Asynchronous method calls CC PC PC Output interfaces Export Composite component

Invalid composition Interface exported twice es is a function Output plugged twice e. C is a function y is a function Except with group communication …

Output interfaces Input interfaces Valid Compositions

Output interfaces Input interfaces Semantics: “Static” Translation to ASP

Output interfaces Input interfaces Semantics: “Dynamic” Translation to ASP

ASP Components: Characteristics l l Well defined interfaces: served methods (should correspond to potential services) Structured communications: Requests = Asynchronous method calls Concurrent and Distributed: Primitive components as an abstraction for activities (threads) Inherit futures, data-driven synchronization and asynchrony from ASP

Content I. Context: Distributed Components and Active Objects II. Asynchronous Distributed Components III. Deterministic Distributed Components

Deterministic Primitive Component l Requirement on potential services: Each Potential service is entirely included in a single SI A Primitive Component Serve(M)

Deterministic Composition Each SI is only used once, either bound or exported: Non-confluent

Summary and Results l A definition of components - Coarse grain components (activities) - Convenient abstraction for distribution and Concurrency - Structured asynchronous communications Components provide - Semantics as a translation to ASP convenient - First a class futures inheritedabstraction from ASP for statically ensuring determinism l Specification of deterministic components: - Deterministic primitive components - Deterministic composition of components

A Few Perspectives l l Behavioral specification of component composition (ongoing) Specify and study non-functional aspects - l in particular life-cycle and reconfiguration in a distributed environment A Formal basis fo the Grid Component Model (GCM) -together with the kell-calculus - Collective interfaces - Grid specifices (distribution and heterogeneity) - Put together hierarchy, structured communications and non-functional aspects

Structure a b foo f 2 f 1 foo g d f 3 Active(a)

Sending Requests ( REQUEST ) a b beta. foo(b) foo result=beta. foo(b)

Sending Requests ( REQUEST ) a b beta. foo(b) result foo result=beta. foo(b)

Sending Results a ( REPLY ) b foo

Sending Results a ( REPLY ) b foo

Future Update Strategies a b delta. send(result) result. bar() d g

Future Update Strategies: No partial replies and request a b delta. send(result) d

Future Update Strategies: Message-based a b Future Forwarded Messages delta. send(result) result. bar() d g

Future Update Strategies: Forward-based a b delta. send(result) result. bar() d g

Future Update Strategies: Lazy Future Updates a b delta. send(result) result. bar() d g