Download presentation
Presentation is loading. Please wait.
Published byJoel Holt Modified over 8 years ago
1
Asynchronous Distributed Components: Concurrency and Determinacy I. Context: Distributed Components and Active Objects II. Asynchronous Distributed Components III. Deterministic Distributed Components Denis CAROMEL Ludovic HENRIO TCS 2006 - 23/08/2006
2
I. Context: Distributed Components and Active Objects II. Asynchronous Distributed Components III. Deterministic Distributed Components Content
3
Context l Fractal: a component model specification l An implementation in ProActive Hierarchical composition Asynchronous, distributed components Non-functional aspects and lifecycle l Formal aspects Kell calculus component control (passivation) ASP components Communication, hierarchy and deterministic components
4
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, …
5
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. Potential Service : an approximation of the set of services (set of methods M) that can appear in the Serve(M) instructions that an activity may perform in the future. = {{foo,bar},{gee}}
6
Deterministic Object Networks {foo,bar}, {foo,gee} delta.gee(a) gee delta.bar(a) bar {bar,gee}, {foo} gee barbar gee DON(P):
7
Static DON {foo,bar}, {gee} {gee}, {f,g} {bar}, {gee} {foo,bar}, {gee} foo bar f {foo}, {bar} {gee}, {f,g} {f,g} {gee}, {f,g} f g gee f g {gee}, {f,g} g The difficulty is to statically approximate activities, method calls and potential services The difficulty is to statically approximate activities, method calls and potential services
8
I. Context: Distributed Components and Active Objects II. Asynchronous Distributed Components III. Deterministic Distributed Components Content
9
Primitive Components A Primitive Component Server Interfaces Client Interfaces Requests Method names Fields Requests
10
Hierarchical Composition Composite component Primitive component PC CC Input interfaces Output interfaces Asynchronous method calls Export Binding
11
Invalid composition Interface exported twiceOutput plugged twice Except with group communication … s is a function C is a function is a function
12
Valid Compositions Input interfaces Output interfaces
13
Semantics: “Static” Translation to ASP Input interfaces Output interfaces
14
Semantics: “Dynamic” Translation to ASP Input interfaces Output interfaces
15
ASP Components: Characteristics l Well defined interfaces: served methods (should correspond to potential services) l Structured communications: Requests = Asynchronous method calls l Concurrent and Distributed: Primitive components as an abstraction for activities (threads) l Inherit futures, data-driven synchronization and asynchrony from ASP
16
I. Context: Distributed Components and Active Objects II. Asynchronous Distributed Components III. Deterministic Distributed Components Content
17
Deterministic Primitive Component l Requirement on potential services: Each Potential service is entirely included in a single SI A Primitive Component Serve(M)
18
Deterministic Composition Non-confluent Each SI is only used once, either bound or exported:
19
Summary and Results l A definition of components Coarse grain components (activities) Convenient abstraction for distribution and Concurrency Structured asynchronous communications Semantics as a translation to ASP First class futures inherited from ASP l Specification of deterministic components: Deterministic primitive components Deterministic composition of components Components provide a convenient abstraction for statically ensuring determinism Components provide a convenient abstraction for statically ensuring determinism
20
A Few Perspectives l Behavioral specification of component composition (ongoing) l Specify and study non-functional aspects in particular life-cycle and reconfiguration in a distributed environment l 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
22
f3 f1 Structure foo f2 Active(a)
23
foo beta.foo(b) result=beta.foo(b) Sending Requests ( REQUEST )
24
foo beta.foo(b) result result=beta.foo(b) Sending Requests ( REQUEST )
25
foo Sending Results( REPLY )
26
foo
27
delta.send(result) result.bar() Future Update Strategies
28
delta.send( result ) Future Update Strategies: No partial replies and request
29
delta.send(result)result.bar() Future Update Strategies: Message-based Future Forwarded Messages
30
delta.send(result)result.bar() Future Update Strategies: Forward-based
31
delta.send(result)result.bar() Future Update Strategies: Lazy Future Updates
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.