1 / 21

Denis Caromel Joint work with Ludovic Henrio – Eric Madelaine et. OASIS members OASIS Team

Theory to Practice in Distributed Component Systems. Denis Caromel Joint work with Ludovic Henrio – Eric Madelaine et. OASIS members OASIS Team INRIA -- CNRS - I3S – Univ. of Nice Sophia-Antipolis, IUF Keynote talk at Formal Aspects of Component Systems, FACS, Prague, Sept. 2006.

umeko
Download Presentation

Denis Caromel Joint work with Ludovic Henrio – Eric Madelaine et. OASIS members OASIS Team

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Theory to Practice in Distributed Component Systems Denis Caromel Joint work with Ludovic Henrio – Eric Madelaine et. OASIS members OASIS Team INRIA -- CNRS - I3S – Univ. of Nice Sophia-Antipolis, IUF Keynote talk at Formal Aspects of Component Systems, FACS, Prague, Sept. 2006

  2. Theory to Practice in Distributed Component Systems Statement a: Prog. Language – Model / Semantics Statement b.: Active Objects 1. DistributedObjects: Active Objects 2. Calculus: ASP 3. Dist. Component Specification: GCM 4. Middleware: ProActive 5. Model Checking: Vercors Denis Caromel Joint work with Ludovic Henrio – Eric Madelaine et. OASIS members

  3. Practice to Theory to Practice in Distributed Component Systems Statement a: Prog. Language – Model / Semantics Statement b.: Active Objects 1. DistributedObjects: Active Objects 2. Calculus: ASP 3. Dist. Component Specification: GCM 4. Middleware: ProActive 5. Model Checking: Vercors Denis Caromel Joint work with Ludovic Henrio – Eric Madelaine et. OASIS members

  4. Features for Scalable, Distributed Objects and Components • Asynchronous Calls • 1st Class Futures • Typed Groups

  5. Features for Component Verifications • Wait-by-Necessity • Future Update can occur anytime (no consequences) • No sharing • No user-, code-level, concurrency and parallelism • Insensitive Semantics to Distribution / Location

  6. 1. Active ObjectsProgramming

  7. ProActive model (1) • Java RMI (Remote Method Invocation = Object RPC = o.foo(p) ) • plus a few important features: • Asynchronous Method calls towards Active Objects: Implicit Futures as RMI results • Wait-By-Necessity: • Automatic wait upon the use of an implicit future • First-Class Futures: - Futures passed to other activities - Sending a future is not blocking

  8. JVM A A WBN! ProActive : Active objects A ag =newActive (“A”, […], VirtualNode) V v1 = ag.foo (param); V v2 = ag.bar (param); ... v1.bar(); //Wait-By-Necessity JVM ag v2 v1 V Wait-By-Necessity is a Dataflow Synchronization Java Object Active Object Req. Queue Future Object Proxy Thread Request

  9. b.foo(x, c) Copy: at serialization Call between Objects: Parameter Passing: Active Objects Object passed by Deep Copy - Active Object by Reference a b x c Reference Passing c

  10. Interleaving-Free Synchronizations

  11. ProActive : Intra-object synchronization class BoundedBuffer extends FixedBuffer implements RunActive{ // Programming Non FIFO behavior runActivity (ExplicitBody myBody) { while (...) { if (this.isFull()) serveOldest("get"); else if (this.isEmpty()) serveOldest ("put"); else serveOldest (); // Non-active wait waitArequest (); } }} • Explicit control: • Library of service routines: • Non-blocking services,... • serveOldest (); • serveOldest (f); • Blocking services, timed, etc. • serveOldestBl (); • serveOldestTm (ms); • Waiting primitives • waitARequest(); • etc. Implicit (declarative) control: library classes e.g. : Blocking Condition Abstraction for concurrency control: doNotServe ("put", "isFull");

  12. First-Class FuturesUpdate

  13. V= b.bar () b v v Wait-By-Necessity: First Class Futures Futures are Global Single-Assignment Variables a b c.gee (V) c c

  14. Future update strategies • No partial replies and requests: • No passing of futures between activities, more deadlocks • Eager strategies: as soon as a future is computed • Forward-based: • Each activity is responsible for updating the values of futures it has forwarded • Message-based: • Each forwarding of future generates a message sent to the computing activity • The computing activity is responsible for sending the value to all • Mixed strategy: • Futures update any time between future computation and WbN • Lazy strategy: • On demand, only when the value of the future is needed (WbN on it)

  15. V= b.bar () b v v Wait-By-Necessity: Eager Forward Based AO forwarding a future: will have to forward its value a b c.gee (V) c c

  16. V= b.bar () b v v Wait-By-Necessity: Eager Message Based AO receiving a future: send a message a b c.gee (V) c c

  17. V= b.bar () v v Wait-By-Necessity: Lazy Strategy An Active Object requests a Future Value when needed a b c.gee (V) c c

  18. TYPED ASYNCHRONOUS GROUPS

  19. A V Creating AO and Groups A ag = newActiveGroup (“A”, […], VirtualNode) V v = ag.foo(param); ... v.bar(); //Wait-by-necessity JVM Group, Type, and Asynchrony are crucial for Cpt. and GRID Typed Group Java or Active Object

  20. ag JVM c3 c3 c3 c3 c3 c3 c3 c1 c1 c1 c1 c1 c1 c1 c2 c2 c2 c2 c2 c2 c2 JVM JVM s s JVM Broadcast and Scatter cg ag.bar(cg); // broadcast cg ProActive.setScatterGroup(cg); ag.bar(cg); // scatter cg

  21. next

More Related