Download
update strategies for first class futures n.
Skip this Video
Loading SlideShow in 5 Seconds..
Update Strategies for First Class Futures PowerPoint Presentation
Download Presentation
Update Strategies for First Class Futures

Update Strategies for First Class Futures

111 Vues Download Presentation
Télécharger la présentation

Update Strategies for First Class Futures

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Update Strategies for First Class Futures Khan Muhammad, Ludovic Henrio INRIA, Univ. Nice Sophia Antipolis,CNRS

  2. Introduction / Contributions • Semi-formal event-like notation • Compromise between easy to read and precision • Cost analysis of the strategies • Cost in terms of message exchanges • Experimental Evaluation • Verifying the results of the cost analysis Goal: Analysis of future update strategies Which is the best future update strategy?

  3. Table of Contents • Background & Related Work • Future Update Strategies • Semi-formal notation for modeling strategies • Cost analysis & Experimental evaluation • Conclusion & Future directions

  4. Message Queue Pending Requests A Activity thread Membrane (Body) Passive Objects Active Objects (Overview)

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

  6. Context • Active Objects • Single Activity Thread: no shared memory • Message Queue • Futures • Creation: Explicit/implicit • Access: Explicit vs transparent • First class futures: transmit futures between AO • Increases parallelism • Wait by necessity (Strict operations) • Data flow synchronization

  7. Related Work • Lambda Calculus, Multi-Lisp, ABCL/f • Not first class futures • Creol • Explicit future Creation • Explicit access • Ambient Talk • Future access is asynchronous • No synchronization

  8. Table of Contents • Background & Related Work • Future Update Strategies • Semi-formal notation for modeling strategies • Cost analysis • Experimental evaluation • Conclusion & Future directions

  9. Future update strategies • Can be divided in two categories • Eager • Future updated as soon as result is available • Lazy • On demand / “need to know” future update • Eager Strategies • Eager forward-based • Eager message-based • Lazy • Lazy message-based • No Partial Replies & requests • No First-class futures

  10. Future Update Strategies: No partial replies and request a b Cannot Pass Future references between ActiveObjects delta.send(result) d

  11. Future Update Strategies: First Class Futures a b Only operations that manipulate future value are blocking result = beta.get() delta.send(result) Result.bar() d g gamma.send(param)

  12. Future Update Strategies: Forward-based a b delta.send(result) result.bar() result.bar() d g

  13. Future Update Strategies: Forward-based a b delta.send(result) result.bar() result.bar() d g

  14. Future Update Strategies: Forward-based a b Future updates follow the same path as future references delta.send(result) result.bar() result.bar() d g

  15. Future Update Strategies: Forward-based (summary) • All futures references are eventually updated • Future update starts as soon as value is computed • Each AO is responsible for updating futures it has forwarded • Future updates follow the same path as futures • Future value may need to pass through “n” intermediate hops • Future value is serialized and de-serialized at each intermediate node • Once the value is updated, no need to store it further

  16. Future Update Strategies: Message-based a b delta.send(result) result.bar() result.bar() d g

  17. Future Update Strategies: Message-based a b delta.send(result) result.bar() result.bar() d g

  18. Future Update Strategies: Message-based a b delta.send(result) result.bar() result.bar() d Future Registration Messages g

  19. Future Update Strategies: Message-based(2) a b Additional Registration Messages required result = beta.get() delta.send(result) Result.bar() d g gamma.send(param)

  20. Future Update Strategies: Message-based (Summary) • Centralized future updates • All updates are performed by “Home” node • Future update starts as soon as value is computed • Additional “future registration” messages needed • One-to-many communication to avoid multiple serializations • Computed results are stored until all futures have been updated

  21. Future Update Strategies: lazy(2) a b result = beta.get() delta.send(result) Result.bar() d g gamma.send(param)

  22. Future Update Strategies: lazy(2) a b result = beta.get() delta.send(result) Result.bar() d g gamma.send(param)

  23. Future Update Strategies: Lazy Future Updates a b “on demand” future update delta.send(result) result.bar() result.bar() d g

  24. Future Update Strategies: Lazy Strategy (Summary) • Centralized future update • Least number of messages exchanged (unless Worst case) • On demand registration and update • Additional delay • Good when only some nodes need the future value • No need to update intermediate nodes

  25. Table of Contents • Background & Related Work • Future Update Strategies • Semi-formal notation for modeling strategies • Cost analysis & Experimental evaluation • Conclusion & Future directions

  26. Semi-formal notation for strategies • Modeled as combination of operations & events • Operations • Register future (Reg) • Locally update future with value (Update) • Clear future from list (Clear) • Send future value (SendValue) • Events • Create future (Create) • Send future reference (SendRef) • Future Computed (FutureComputed) • Wait by necessity (Wait)

  27. Eager Message-based Strategy (semi-formal notation) Compromise between “readability” and precision

  28. Table of Contents • Background & Related Work • Future Update Strategies • Semi-formal notation for modeling strategies • Cost analysis & Experimental evaluation • Conclusion & Future directions

  29. Comparison/Cost Analysis Simple model to allow reasoning about strategy selection at abstract lvl • “Computation time” is not taken into account (application dependent) • Only “time to update future” • Assumes that result has been computed when the registration request is received

  30. Experiment Result (1)

  31. Experiment Results (2)

  32. Table of Contents • Background & Related Work • Future Update Strategies • Semi-formal notation for modeling strategies • Cost analysis & Experimental evaluation • Conclusion & Future directions

  33. Conclusion & Future directions (1) • Selection of a strategy depends on application nature (and configuration) • Eager forward-based: • Most nodes actually require future value • Small number of intermediate nodes • Size of transferred data is “not huge” • Message-based: • Most nodes actually require future value • No network constraints • Constant future update time needed (single hop) • Lazy message-based: • Only few nodes actually require future value • Future value is “too large” • Long term storage of values is not a concern

  34. Merci ! Conclusion & Future directions (2) • Garbage Collection of computed Futures for message-based strategies • Protocol for “cancel future update” for objects not interested in future value (a un-register message) • Canceling a request • Migration: for message-based strategies

  35. Experimental Setting Trees of different heights Pipe of varying length f f f f f f

  36. Experimental Setting • Exp (1) • Tree configuration (varying height & degree) • Fixed future size of (20 MB) • Tree of 30 nodes • Only leaf nodes (8 max) a perform strict operation • Cluster of 10 physical Nodes (university of sannio) • Exp (2) • Pipe of varying length • Only last node in pipe makes a strict operation • Fixed future size (20 MB)

  37. Current implementation status • Currently a prototype implementation with university of sannio • Does not fit well with current AC mechanism • Does not reuse ProActive’s AC mechanisms • Functionality is spread over different classes -> Need to be brought in-line with the AC mechanism of ProActive. • No garbage collection for computed results +registration requests • Home-based strategies are implemented using a “reference to home” (body) in FutureProxy (will cause problems for migration) • Additional class “RequestForFuture.java added to implement registration • Implementing a multi-threaded future update mechanism with unique-serialization

  38. Wait-by-necessity a b delta.send(result) d

  39. Wait-by-necessity result.bar() a b delta.send(result) result.bar() d

  40. Wait-by-necessity result.bar() a b delta.send(result) result.bar() d

  41. Wait-by-necessity a b Futures updates can occur at any time result.bar() d