2. calculus:
DESCRIPTION
2. CALCULUS:. A S P. THEORY. A Theory of Distributed Objects D. Caromel, L. Henrio, Springer 2005, Monograph. A Calculus: ASP: Asynchronous Sequential Processes Based on Sigma-Calculus ( Abadi-Cardelli ) Formal Proofs of determinism - PowerPoint PPT PresentationTRANSCRIPT
2. CALCULUS:
A S P
A Theory of Distributed ObjectsD. Caromel, L. Henrio,
Springer 2005, Monograph
A Calculus:
ASP: Asynchronous Sequential Processes Based on Sigma-Calculus (Abadi-Cardelli) Formal Proofs of determinism Releases a few important implementation constraints
THEORY
-calculus
Why calculi?Prove properties on languages, typing
Programs (equivalence), execution strategies, …
Why calculi?Prove properties on languages, typing
Programs (equivalence), execution strategies, …
Review (informal classification of calculi)
Asynchronous and Deterministic Objects
ASP: Asynchronous Sequential Processes
Distributed objects
Asynchronous method calls ( towards components)
Futures and Wait-by-necessity
Determinism properties
A Theory of Distributed Objects
ASP Syntax : Source Terms Imperative-calculus
ASP parallelism primitives
1- ASP
Local
Creating anActivity
Sending aRequest
Sending aReply
Service
1- ASP
f3
f1
Structure
1- ASP
foo
foo
f2
Active(a)
foo
beta.foo(b)
result=beta.foo(b)
Sending Requests ( REQUEST )
1- ASP
foo
beta.foo(b)result
Sending Requests ( REQUEST )
1- ASP
result=beta.foo(b)
delta.send(result)
Wait-by-necessity
1- ASP
delta.send(result)result.bar()result.bar()
Wait-by-necessity
1- ASP
delta.send(result)result.bar()result.bar()
Wait-by-necessity
1- ASP
Wait-by-necessity
result.bar()Futures updates can occur at any time
Futures updates can occur at any time
1- ASP
Confluence and Determinacy
Store Partitioning
Deterministic Object Networks
{foo,bar} , {foo,gee}
delta.gee(a)
gee
delta.bar(a)bar
{bar,gee} , {foo}
gee barbar gee
DON(P):
ASP theory: Summary and Results
ASP Confluence and Determinacy Proved Properties:
Future updates can occur at any time, in any order
Asynchronous FIFO point-to-point is enough for Requests
Execution characterized by the order of request senders
Applications:
Determinacy of programs based on a dynamic property: DON
Determinacy of programs communicating over Trees,
SDON, and Deterministic Components, …
Static DON
{foo,bar} , {gee}
{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 staticallyapproximate activities, method calls
and potential services
The difficulty is to staticallyapproximate activities, method calls
and potential services
From 2. to 3.:CALCLUS to COMPONENTS
Components in ASP
Objective: Deterministic Components
Content
Controller
Using the Fractal model:Hierarchical Component
Defined by E. Bruneton, T. Coupaye, J.B. Stefani, INRIA & FT
Content
Controller
Hierarchical model : Composites encapsulate Primitives,
Primitives encapsulate Code
Content
Controller
Binding = in an external file (XML ADL), Not in programs
Content
Controller
Binding = in an external file (XML ADL), Not in programs
Context and Challenge
- Asynchronous,
- Distributed components, yet
Deterministic Components
Primitive Components
A PrimitiveComponent
Server InterfacesClient Interfaces
Requests
Method names
Fields
Requests
Hierarchical Composition
Composite component
Primitive component
PC
PC PCCC
Inp
ut
inte
rfac
esO
utp
ut in
terfaces
Asynchronousmethod calls
Exp
ort
Exp
ort
Binding
Invalid composition
Interface exported twice Output plugged twice
Except with group communication …
s is a functionC is a function
is a function
Valid Compositions
Non-confluent
Non-confluent
Non-confluent
Inp
ut
inte
rfac
esO
utp
ut in
terfaces
Valid CompositionsIn
pu
t in
terf
aces
Ou
tpu
t interfaces
Semantics: “Static” Translation to ASPIn
pu
t in
terf
aces
Ou
tpu
t interfaces
Semantics: “Dynamic” Translation to ASPIn
pu
t in
terf
aces
Ou
tpu
t interfaces
Deterministic Primitive Component
Requirement on potential services:
Each Potential service isentirely included in a single SI
A PrimitiveComponent
Serve(M)
Deterministic Composition (SDON)
Non-confluent
Non-confluent
Non-confluent
Each SI is only used once, either bound or exported:
Component Model: Summary and Results
A definition of components Coarse grain components (activities) Convenient abstraction for distribution and Concurrency:
Primitive components as an abstraction for activities Structured asynchronous communications
Requests = Asynchronous method calls Well defined interfaces: served methods Semantics as translations to ASP First class futures inherited from ASP
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
Towards Parallel and Deterministic Components
Groups in ASP
Group.foo()
Groups of Active Objects
3 – More FeaturesPart IV
Group.foo()
Groups of Active Objects
foo
foo
foo
result
3 – More FeaturesPart IV
Group.foo()
Groups of Active Objects
foo
foo
foo
Group.bar()
bar
bar
bar
3 – More FeaturesPart IV
Group.foo()
Groups of Active Objects: Atomic Communications
foo
foo
foo
Group.bar()
bar
bar
bar
Some programs become deterministic with
Atomic Group Communications
Some programs become deterministic with
Atomic Group Communications
Non Det. Prog. Det. Prog. with GroupsNon Det. Prog. Det. Prog. with Groups
3. Distributed Component Specification Cp. in Practice
GCM: Grid Component Model
GCM: Grid Component Model GCM Being defined in the NoE CoreGRID
(42 institutions) Open Source ObjectWeb ProActive
implements a preliminary version of GCM
GridCOMP takes: GCM as a first specification, ProActive as a starting point, and
Open Source reference implementation.
GCM Components
Scopes and Objectives:
- Grid Codes that Compose and Deploy
- No programming, No Scripting, … No Pain
The vision: The vision: GCMGCM to be the GRID to be the GRID GSMGSM for Europe for Europe
Collective Interfaces
Collective Interfaces
Simplify the design and configuration of component systems
Expose the collective nature of interfaces Cardinality attribute Multicast, Gathercast, gather-multicast
The framework handles collective behaviour at the level of the interface
Based on Fractal API : Dedicated controller Interface typing Verifications
Multicast interfaces
Transform a single invocation into a list of invocations
Multiple invocations Parallelism Asynchronism Dispatch
Data redistribution (invocation parameters) Parameterisable distribution function Broadcast, scattering Dynamic redistribution (dynamic dispatch)
Result = list of results
Multicast interfaces
Results as lists of results
Invocation parameters may also be distributed from lists
Gathercast interfaces
Transform a list of invocations into a single invocation
Synchronization of incoming invocations
~ “join” invocations Timeout / Drop policy Bidirectional Bindings
(callers callee)
Data gathering
Aggregation of parameters
into lists
Result: redistribution of results
Redistribution function
Virtual Nodes
Permits a program to generate automatically a deployment plan: find the appropriate nodes on which processes should be launched.
In the future, we envisage the adjunction of more sophisticated descriptions of the application needs with respect to the execution platform: topology, QoS, …
Virtual Nodes in the ADL
Renames a VN Exports a VN name
The final version of the GCM specification will precisely define the syntax for the virtual node definition, and their composition.
NEXT: Part 4. Middleware: ProActive
Services in ASP
Pending requests are stored in a queue.
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}}
Perspectives: Distributed Components
Behavioral specification of component composition (ongoing)
Specify and study non-functional aspects 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 specifics (distribution and heterogeneity) Put together hierarchy, structured communications and
non-functional aspects
PerspectivesPart VI
Equivalence Modulo Futures Updates
f1
f2
f3
Part III
Appendices
ASP Components: Characteristics
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
ComponentsPart IV
A Deterministic Component
Based on deterministic primitive components. One-to-one mapping from Server to client interface
ComponentsPart IV
Equivalence Modulo Futures Updates (1)
f3
2 - Confluence and DeterminacyPart III
Equivalence Modulo Futures Updates (2)
f1
f2
f3
f1
f2
2 - Confluence and DeterminacyPart III
Equivalence Modulo Future Updates (2)
f2
f3
f1
f1
f2
f1
2 - Confluence and DeterminacyPart III
Compatibility
delta.foo()
foo
….Serve(foo,bar)
…Serve(foo,gee)
bar
gee
2 - Confluence and Determinacy
Serves the oldest request on foo OR bar
Part III
Confluence
Potential services:
2 - Confluence and Determinacy
P0
P Q
R
….Serve(foo,bar)
…Serve(foo,gee)
{foo,bar}, {foo,gee}
Part III
Confluence
Potential services:
2 - Confluence and Determinacy
RSL definition:
foo, bar, bar, gee
P0
P Q
R
{foo,bar}, {foo,gee}
Part III
Confluence
Potential services:
2 - Confluence and Determinacy
RSL definition:
Configuration Compatibility:
P0
P Q
R
{foo,bar}, {foo,gee}
foo, bar, bar, gee
foo, bar, bar, gee foo, bar, gee, barfoo, bar, bar, gee foo, bar, gee, barfoo, bar, bar, gee foo, bar, gee, bar
Part III
Confluence
Potential services:
2 - Confluence and Determinacy
RSL definition:
Compatibility Confluence
Configuration Compatibility:Execution characterized
by the order of request sendersExecution characterized
by the order of request senders
P0
P Q
R
Part III
Deterministic Object Networks
{foo,bar} , {foo,gee}
delta.gee(a)
gee
delta.bar(a)bar
{bar,gee} , {foo}
gee barbar gee
2 - Confluence and Determinacy
DON(P):
Part III
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, …
Contents
A Theory of Distributed Objects
1 - ASP
2 - Confluence and Determinacy
3 - More Features: Groups
4 – Implementation Strategies: Future Updates
ASP Components
Perspectives
Implementation Strategies
ProActive
Future Update Strategies Futures are first class and can be returned at any time Lazy / Forward-based / Message-based.
Loosing Rendez-Vous Ensuring causal ordering with one-to-all FIFO ordering Comparison with other strategies, e.g. point-to-point
FIFO
Controlling Pipelining
4 – Implementation StrategiesPart V
Future Updates Summary
Mixed strategies are
possible
All strategies are
equivalent
(modulo dead-locks)
Part V, VI 4 – Implementation Strategies
Overview of Implementation Strategies: Queues, Buffering, Pipelining, and Strategies
Perspectives:
• Organize and synchronize implementation
strategies
• Design a global adaptative evaluation strategy
Perspectives:
• Organize and synchronize implementation
strategies
• Design a global adaptative evaluation strategy
Part VI 4 – Implementation Strategies
Services in ASP
Pending requests are stored in a queue.
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}}
Deterministic Object Networks
{foo,bar} , {foo,gee}
delta.gee(a)
gee
delta.bar(a)bar
{bar,gee} , {foo}
gee barbar gee
DON(P):