1 / 26

Multi-threaded Active Objects

Multi-threaded Active Objects . Ludovic Henrio, Fabrice Huet, Zsolt Istv à n. 6 /2013 – Coordination (Firenze). Agenda. Introduction: Active Objects Issues and Existing Solutions Multi-active Objects : Principles Experiments and Benchmarks Conclusion and Future Works.

emelda
Download Presentation

Multi-threaded Active Objects

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. Multi-threaded Active Objects Ludovic Henrio, Fabrice Huet, ZsoltIstvàn 6/2013 – Coordination (Firenze)

  2. Agenda • Introduction: Active Objects • Issues and Existing Solutions • Multi-active Objects: Principles • Experimentsand Benchmarks • Conclusion and Future Works

  3. ASP / ProActive • Active objects, asynchronous communication • Asynchronous method calls with implicit transparent futures • A β = newActive (“A”, …) • V foo = β.bar(param) • ….. • foo.getval( ) a b foo= beta.bar(p) Active objects are the unit of distribution and concurrency (one thread per AO / no data shared) ProActive is a Java library implementing ASP foo.getval( ) foo.getval( ) foo.getval( ) WBN!! Caromel, D., Henrio, L.: A Theory of Distributed Object. Springer-Verlag (2005)

  4. First Class Futures a b f delta.snd(foo) d

  5. Agenda • Introduction: Active Objects • Issues and Existing Solutions • Multi-active Objects: Principles • Experimentsand Benchmarks • Conclusion and Future Works

  6. Active Objects – Limitations • No data sharing – inefficient local parallelism • Parameters of method calls are passed by value • No data race-condition simpler programming + easy distribution • Inefficient local parallelism • Risks of deadlocks, e.g. no re-entrant calls • Active object are single threaded • Re-entrance: Active object deadlocks by waiting on itself (except if first-class futures) • Solution: Modifications to the application logic difficult to program AO1 AO2

  7. Related Work (1): Cooperative multithreading Creol an Jcobox: • Active objects & futures • Cooperative multithreading • All requests servedat the same time • But only one thread active at a time • Explicit release points in the code • Partially solves the re-entrance problem • More difficult to program: less transparency • Possible interleaving still has to be studied (service order?)

  8. Related Work (2): JAC • Declarative parallelization in Java • Expressive (complex) set of annotations • “Reactive” objects • Simulating active objects is possible but not trivial An alternative view: we adapt a simple version of JAC to simple active objects a la ASP to get efficient and easy to program multi-active objects

  9. Agenda • Introduction: Active Objects • Issues and Existing Solutions • Multi-active Objects: Principles • Experimentsand Benchmarks • Conclusion and Future Works

  10. Multi-active objects • A programmingmodel that mixes local parallelism and distribution withhigh-levelprogrammingconstructs • Executeseveralrequests in parallel but in a controlledmanner join() Providedadd, add and monitor are compatible add() { … … } monitor(){… … } add() { … }

  11. SchedulingRequests • An « optimal » requestpolicythat « maximizesparallelism »: • Schedule a new request as soon as possible (whenitis compatible with all the servedones) • Serve it in parallelwith the others • Serves • Either the first request • Or the second if itis compatible with the first one (and the servedones) • Or the third one … compatible

  12. Declarative concurrency by annotating request methods • Groups • (Collection of related methods) • Rules • (Compatibility relationships between groups) Memberships (To which group each method belongs)

  13. More efficiency: Thread management • Too many threads can be harmful: • memory consumption, • too much concurrency wrt number of cores • Possibility to limit the number of threads • Hard limit: strict limit on the number of threads • Soft limit: prevents deadlocksLimit the number of threads that are not in a WBN

  14. Dynamic compatibility: Principle • Compatibility maydepend on object’s state or methodparameters join() Providedthe parameters of add are different add(int n) { … … } add(int n) { … }

  15. Dynamic compatibility: annotations • Define a common parameter for methods in a group • a comparison function between parameters (+local state) to decide compatibility

  16. Hypothesesand programmingmethodology • We trust the programmer : annotations are considered as correct; staticanalysis or dynamicchecksshouldenforcecorrectness in the future • Without annotations, a multi-active objectrunslike an active object • If more parallelismisrequired: • Add annotations corresponding to non-conflictingmethods • Declaredynamic compatibility (seenextslide) • Protectsomememoryaccess (e.g. by locks) and add new annotations • More parallelismMorecomplex code / better performance Easy to program Difficult to program

  17. Agenda • Introduction: Active Objects • Issues and Existing Solutions • Multi-active Objects: Principles • Experiments and Benchmarks • Conclusion and Future Works

  18. Experiment#1: NAS parallel benchmark • Pure parallel application (Java) • No distribution • Comparisonwith hand-written concurrent code • Shows thatwith multi-active objects, parallelcode • Is simplerand shorter • With similarperformance

  19. Multi-active objects are simpler to program Original vs. Multi-active object master/slave pattern for NAS

  20. Performance are similar to hand-writtenconcurrency • Less synchronisation/concurrency code • Withsimilar performances

  21. Experiment#2: CAN Eachpeerisimplemented by a (multi) active object and placed on a machine • Featuresparallelism and distribution • Parallelrouting

  22. Experiment#2: CAN Significant speedup due to parallelisation of communications, while controlling which communications are performed in parallel

  23. Agenda • Introduction: Active Objects • Issues and Existing Solutions • Multi-active Objects: Principles • Experimentsand Benchmarks • Conclusion and Future Works

  24. Conclusion (1/2): a new programming model • Multi-active objects feature: • Active object model • Easy to program • Support for distribution • Local concurrencyand efficiency on multi-cores • Transparent multi-threading • Safe parallel execution • Possibility to write non-blocking re-entrant code • Simple annotations A programming model for locally concurrent and globally distributed objects

  25. Conclusion (2/2): ResultsandStatus • Implemented multi-active objectsaboveProActive Dynamiccompatibility rules and thread limitation • Case studies/benchmarks: NAS, CAN • Specified the semantics of Multi-ASP • Provedthatparallelismismaximised: • Tworequestsserved by twodifferent threads are compatible • Eachrequestisincompatible withanotherrequestserved by the same thread (thatprecedeit) • Nextsteps: • Staticguarantees/verification of annotations • Use the new model (new use-cases and applications) • Provestrongerproperties, mechanisedformalisaiton

  26. Conclusion (2/2): ResultsandStatus • Implemented multi-active objectsaboveProActive Dynamiccompatibility rules and thread limitation • Case studies/benchmarks: NAS, CAN • Specified the semantics of Multi-ASP • Provedthatparallelismismaximised: • Tworequestsserved by twodifferent threads are compatible • Eachrequestisincompatible withanotherrequestserved by the same thread (thatprecedeit) • Nextsteps: • Staticguarantees/verification of annotations • Use the new model (new use-cases and applications) • Provestrongerproperties, mechanisedformalisaiton

More Related