Asynchronous Distributed Components: Concurrency and Determinacy

1
Asynchronous Distributed ComponentsConcurrency
and Determinacy
Denis CAROMEL Ludovic HENRIO

1. Context Distributed Components and Active
   Objects
2. Asynchronous Distributed Components
3. Deterministic Distributed Components

TCS 2006 - 23/08/2006
2
Content

1. Context Distributed Components and Active
   Objects
2. Asynchronous Distributed Components
3. Deterministic Distributed Components

3
Context

• Fractal a component model specification
• An implementation in ProActive
• Hierarchical composition
• Asynchronous, distributed components
• Non-functional aspects and lifecycle
• 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

• 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 a may
  perform in the future.
  foo,bar,gee

6
Deterministic Object Networks
g
b
d
foo,bar , foo,gee
bar,gee , foo
gee bar
bar gee
7
Static DON
a
d
f
foo,bar , gee
gee, f,g
foo,bar , gee
f,g
g
g
g
foo
f
foo,bar , gee
foo, bar
bar
e
f
b
The difficulty is to staticallyapproximate
activities, method calls and potential services
bar , gee
gee, f,g
gee, f,g
gee
8
Content

1. Context Distributed Components and Active
   Objects
2. Asynchronous Distributed Components
3. Deterministic Distributed Components

9
Primitive Components
Requests
A Primitive Component
Requests
Server Interfaces
Client Interfaces
10
Hierarchical Composition
Composite component
Primitive component
PC
Export
Export
Output interfaces
Binding
Asynchronous method calls
Input interfaces
CC
PC
PC
11
Invalid composition
Interface exported twice
Output plugged twice
es is a function
Except with group communication
12
Valid Compositions
Output interfaces
Input interfaces
13
Semantics Static Translation to ASP
Output interfaces
Input interfaces
14
Semantics Dynamic Translation to ASP
Output interfaces
Input interfaces
15
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

16
Content

1. Context Distributed Components and Active
   Objects
2. Asynchronous Distributed Components
3. Deterministic Distributed Components

17
Deterministic Primitive Component

• Requirement on potential services
• Each Potential service isentirely included in a
  single SI

A Primitive Component
Serve(M)
18
Deterministic Composition
Each SI is only used once, either bound or
exported
Non-confluent
Non-confluent
Non-confluent
19
Summary and Results

• 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
• Specification of deterministic components
• Deterministic primitive components
• Deterministic composition of components

Components provide a convenient abstractionfor
statically ensuring determinism
20
A Few Perspectives

• 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 specifices (distribution and heterogeneity)
• Put together hierarchy, structured communications
  and non-functional aspects

21
(No Transcript)
22
Structure
Active(a)
23
Sending Requests ( REQUEST )
a
b
foo
beta.foo(b)
resultbeta.foo(b)
24
Sending Requests ( REQUEST )
a
b
foo
beta.foo(b)
resultbeta.foo(b)
25
Sending Results ( REPLY )
a
b
foo
26
Sending Results ( REPLY )
a
b
foo
27
Future Update Strategies
a
b
delta.send(result)
result.bar()
d
g
28
Future Update Strategies No partial replies and
request
a
b
delta.send(result)
d
29
Future Update Strategies Message-based
a
b
delta.send(result)
result.bar()
result.bar()
d
Future Forwarded Messages
g
30
Future Update Strategies Forward-based
a
b
delta.send(result)
result.bar()
result.bar()
d
g
31
Future Update Strategies Lazy Future Updates
a
b
delta.send(result)
result.bar()
result.bar()
d
g