Safely Stopping Hierarchical Distributed Components: Application to GCM

1
Safely Stopping Hierarchical Distributed
Components Application to GCM

• Ludovic Henrio and Marcela Rivera
• lhenrio,mrivera_at_sophia.inria.fr
• October 2008

2
Agenda

• Introduction and objectives
• Assumptions
• Characteristics of the algorithm
• Algorithm description
• Example
• Conclusion
• Extension and future works

3
Introduction

• When is a system reconfigurable?
• How to stop a hierarchical distributed component
  assembly?
• An algorithm for reaching a safe state.
• First phase of the reconfiguration of components.

4
GCM Component Model

• Extends Fractal component model
• Separation between functional and
  non-functional features
• Components abstract away concurrency and
  distribution

5
Fractal Component
6
A GCM Component System

• Hierarchical system

• Each component has a queue

• Communication by
• asynchronous requests

7
Example of a future
r1
R1
F(R1)
Waiting for the associated value
8
Assumptions

• Requirements
• Absence of deadlocks.
• Absence of livelocks.
• Fairness.
• It is possible to identify the safe state of each
  component.
• Components do not share memory.
• Communications are performed over bindings.
• Components communicate by asynchronous requests.
• It is possible to mark requests.

9
Characteristics of the algorithm

• Not specialized for a given configuration.
• Supports replies (futures).
• If the system cant be stopped safely, the
  algorithm never finishes.
• Stop a component and all its subcomponents.

10
Agenda

• Introduction and objectives
• Assumptions
• Characteristics of the algorithm
• Algorithm description
• Example
• Conclusion
• Extension and futures works

11
Algorithm description

• The master component receives initially the stop
  request.
• First phase preparation
• Only the master component.
• The master marks all requests it sends.
• Second phase stopping the system.
• The master blocks the requests it receives.

12
Algorithm description

• States of the components
• Started.
• Wait for stopping (only master component).
• Stopping.
• Ready to stop. (R2S)
• Stopped.

13
Example
System is stopped!!
(Stopped)
(Waiting for stopping)
(Stopping)
(R2S)
Stopping signal
(Stopping)
(R2S)
(Stopped)
STOP
Blocked
Blocked
(Stopping)
R3
R2
R3
R3
r3
(R2S)
(Stopped)
F(R3)
F(R3)
R3
R3
F(R3)
F(R3)
R2S signal
R1
r3
R2S signal
(Stopped)
(Stopping)
(R2S)
R2S signal
14
Example Not R2S signal
System is stopped!!
(Stopping)
(R2S)
(Stopped)
(Stopping)
(R2S)
STOP
(Stopped)
(Stopping)
(R2S)
(Stopped)
Not_R2S signal
R2S signal
R1
R2S signal
(R2S)
(Stopped)
15
Agenda

• Introduction and objectives
• Assumptions
• Characteristics of the algorithm
• Algorithm description
• Example
• Conclusion
• Extension and futures works

16
Conclusion (1)

• Any component without deadlock nor livelock is
  safely stopped
• The master component is in a strongly idle state
  (quiescent).
• Master queue only contains requests received
  after the last served request.
• The algorithm is independent of the components
  topology and of the components behavior.
• An adaptation of the lifecycle controller of
  Fractal for GCM.

17
Conclusion (2)

• Prototype implementation in GCM/ProActive.
• Synchronization protocol for components
• Being stopped
• Distributed and loosely coupled
• Asynchronous requests
• Few means of synchronization

18
Extension and future works

• Stop several parts of the system.
• Tagging states and requests with the identifier
  of the master.
• Non hierarchical systems
• One central manager.
• Intercepts calls outgoing the assembly.
• Intercepts calls ingoing the assembly.
• Considering hierarchical systems with shared
  components.
• Verify formally the stopping algorithm.

19
Thanks
20
Algorithm description

• Initially all components are in started state.

• The master component changes to waiting for
  stopping state when it receives the stop request.

• While the master is in waiting for stopping state
  it marks all outgoing requests.

• When all requests are marked the master component
  changes to stopping state and it sends the
  stopping signal to its subcomponents.

21
Algorithm description

• When the subcomponents receive the stopping
  signal they change to stopping state.

• When there are no more internal calls to process,
  each components send a R2S signal and change to
  R2S state.

• When the master component receives the R2S signal
  it sends the stop signal for stopped the system.

22
Why marking the requests?
Blocked
Blocked
R3
R3
F(R3)
F(R3)
23
Algorithm for the master component
Only marking requests

• Serving marked requests
• Synchronizing stop thanks
• to R2S state