Execution Support for Multi-Threaded Active Objects : Design and Implementation Justine Rochas

Total Page:16

File Type:pdf, Size:1020Kb

Execution Support for Multi-Threaded Active Objects : Design and Implementation Justine Rochas Execution support for multi-threaded active objects : design and implementation Justine Rochas To cite this version: Justine Rochas. Execution support for multi-threaded active objects : design and implementation. Other [cs.OH]. Université Côte d’Azur, 2016. English. NNT : 2016AZUR4062. tel-01441662 HAL Id: tel-01441662 https://tel.archives-ouvertes.fr/tel-01441662 Submitted on 20 Jan 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. UNIVERSITE´ DE NICE SOPHIA ANTIPOLIS Ecole´ Doctorale STIC Sciences et Technologies de l’Information et de la Communication THESE` pour l’obtention du titre de Docteur en Sciences Mention Informatique pr´esent´eeet soutenue par Justine Rochas Execution Support for Multi-threaded Active Objects: Design and Implementation Th`esedirig´eepar Ludovic Henrio Soutenue le 22 Septembre 2016 Jury Rapporteurs Einar Broch Johnsen University of Oslo Lionel Seinturier Universit´ede Lille Examinateurs Florian Kammuller¨ Middlesex University London Johan Montagnat CNRS Fabrice Huet Universit´ede Nice Sophia Antipolis Directeur de th`ese Ludovic Henrio CNRS ii iii R´esum´e Pour aborder le d´eveloppement d’applications concurrentes et distribu´ees, le mod`ele de programmation `aobjets actifs procure une abstraction de haut niveau pour pro- grammer de fa¸con concurrente. Les objets actifs sont des entit´es ind´ependantes qui communiquent par messages asynchrones. Peu de syst`emes `aobjets actifs consid`erent actuellement une ex´ecution multi-thread´ee. Cependant, introduire un parall´elisme contrˆol´epermet d’´eviter les coˆuts induits par des appels de m´ethodes distants. Dans cette th`ese, nous nous int´eressons aux enjeux que pr´esentent les objets actifs multi-thread´es, et `ala coordination des threads pour ex´ecuter de fa¸con sˆure les tˆaches d’un objet actif en parall`ele. Nous enrichissons dans un premier temps le mod`ele de programmation, afin de contrˆoler l’ordonnancement interne des tˆaches. Puis nous exhibons son expressivit´ede deux fa¸cons diff´erentes: d’abord en d´eveloppant et en analysant les performances de plusieurs applications, puis en compilant un autre langage `aobjets actifs avec des primitives de synchroni- sation diff´erentes dans notre mod`ele de programmation. Aussi, nous rendons nos objets actifs multi-thread´es r´esilients dans un contexte distribu´een utilisant les paradigmes de programmation que nous avons d´evelopp´e. Enfin, nous d´eveloppons une application pair-`a-pair qui met en sc`ene des objets actifs multi-thread´es. Glob- alement, nous concevons un cadre de d´eveloppement et d’ex´ecution complet pour les applications hautes performances distribu´ees. Nous renfor¸cons notre mod`ele de programmation en formalisant nos contributions et les propri´et´es du mod`ele. Cela munit le programmeur de garanties fortes sur le comportement du mod`ele de programmation. iv Abstract In order to tackle the development of concurrent and distributed systems, the active object programming model provides a high-level abstraction to program concurrent behaviours. Active objects are independent entities that communicate by the mean of asynchronous messages. Compared to thread-based concurrent programming, active objects provide a better execution safety by preventing data races. There exists already a variety of active object frameworks targeted at a large range of application domains: modelling, verification, efficient execution. However, among these frameworks, very few of them consider a multi-threaded execution of active objects. Introducing a controlled parallelism within active objects enables overcoming some of their well-known limitations, like the impossibility of commu- nicating efficiently through shared-memory. In this thesis, we take interest in the challenges of having multiple threads inside an active object, and how to safely coordinate them for executing the tasks in parallel. We enhance this programming model by adding language constructs that control the internal scheduling of tasks. We then show its expressivity in two ways: first in a classical approach by developing and analysing the perfor- mance of several applications, and secondly, by compiling another active object programming language with different synchronisation primitives into our program- ming model. Also, we make multi-threaded active objects resilient in a distributed context through generic engineering constructs, and by using our programming abstractions. Finally, we develop a peer-to-peer application that shows multi- threaded active objects and their features in action. Overall, we design a flexible programming model and framework for the development of distributed and highly concurrent applications, and we provide it with a thorough support for efficient distributed execution. We reinforce our programming model by formalising our work and the model’s properties. This provides the programmer with guarantees on the behaviour of the programming model. Remerciements Merci `ames deux rapporteurs pour le temps qu’ils ont accord´e`ala compr´ehension de mes travaux, ainsi qu’aux membres de mon jury de soutenance. Merci `amon directeur de th`ese Ludo avec qui j’ai eu la chance de travailler en collaboration et qui a fait bien plus qu’une mission d’encadrement. Merci `aFabrice qui m’a pr´esent´ee `al’´equipe et qui a toujours su me conseiller dans toutes les facettes que cette th`ese a pu avoir. Merci `aOleksandra pour son support quotidien et son enthousiasme d´ebordant. Merci aux autres membres de l’´equipe, tout particuli`erement `aFabien, Fran¸coise et Eric´ avec qui j’ai pu passer d’agr´eables moments de tous les jours. Merci `ama collaboratrice Sophie et `aLaurent pour son aide pr´ecieuse `amon arriv´ee dans l’´equipe. Merci `aLudwig, mon plus fid`ele auditeur, avec qui j’ai la chance de partager mes int´erˆets professionnels et extra-professionnels. Merci `ames parents qui m’ont fait confiance pour en arriver l`aet `amon fr`ere toujours pr´esent pour nos sorties sportives et comp´etitives. Merci `amon maˆıtre de Taekwondo Pierre grˆace `aqui j’ai pu ponctuer mes semaines d’une ´evasion indispensable. Enfin, merci `atous mes professeurs de l’universit´ede Nice Sophia Antipolis qui m’ont donn´ele goˆut de l’informatique sous tous ses aspects. v vi Table of Contents List of Figures xi List of Listings xv List of Tables xvii 1 Introduction 1 1.1 Motivation................................... 1 1.2 Objectives................................... 3 1.3 Contributions................................. 4 1.4 Outline..................................... 6 2 Background and Related Works 9 2.1 The Active Object Programming Model: Origins and Context .... 10 2.2 A Classification of Active Object Languages . .. 13 2.2.1 ObjectModels ............................ 13 2.2.2 SchedulingModels.......................... 16 2.2.3 Transparency............................. 18 2.3 OverviewofActiveObjectLanguages . 21 2.3.1 Creol.................................. 22 2.3.2 JCoBox ................................ 23 2.3.3 ABS .................................. 25 2.3.4 ASPandProActive......................... 28 2.3.5 AmbientTalk ............................. 31 2.3.6 Encore................................. 33 2.3.7 ActorLanguagesandFrameworks . 35 vii viii TABLE OF CONTENTS 2.4 FocusonMulti-threadedActiveObjects . .. 39 2.4.1 MultiactiveObjectModel . 39 2.4.2 ImplementationinProActive . 41 2.4.3 MultiASP............................... 46 2.5 Determinism in Active Object Executions . .. 47 2.6 PositioningofthisThesis . 52 3 Request Scheduling for Multiactive Objects 57 3.1 Motivation................................... 58 3.2 ThreadingPolicy............................... 60 3.2.1 ThreadLimitperMultiactiveObject . 60 3.2.2 ThreadLimitperGroup . 63 3.3 RequestPriority ............................... 65 3.3.1 Principle ............................... 65 3.3.2 ProgrammingModel ........................ 66 3.3.3 Properties............................... 70 3.3.4 ImplementationandOptimisation . 73 3.4 SoftwareArchitecture ............................ 74 3.5 Evaluation................................... 77 3.5.1 ExperimentalEnvironmentandSetup . 77 3.5.2 HighPriorityRequestSpeedUp . 78 3.5.3 OverheadofPrioritisedExecution . 80 3.6 Conclusion................................... 85 4 From Modelling to Deployment of Active Objects 89 4.1 MotivationandChallenges . 90 4.2 Systematic Deployment of Cooperative Active Objects . ..... 92 4.2.1 AProActiveBackendforABS . 93 4.2.2 Evaluation ..............................105 4.3 Formalisation and Translation Correctness . .110 4.3.1 Recall ofABSand MultiASPSemantics. 110 4.3.2 Semantics of MultiASP Request Scheduling . 119 4.3.3 Translational Semantics and Restrictions . 122 TABLE OF CONTENTS ix 4.3.4 FormalisationofEquivalence . .126 4.4 TranslationFeedbackandInsights . 133 5 Execution Support for Multiactive Objects 139 5.1 Context: ProActive Technical Services . 140 5.2 ADebuggerforMultiactiveObjects . 142 5.2.1 Visualisation of Multiactive Object Notions . 143 5.2.2 IllustrativeUseCases. .148 5.3 A Fault Tolerance Protocol for
Recommended publications
  • Active Object Systems Redacted for Privacy Abstract Approved
    AN ABSTRACT OF THE THESIS OF Sungwoon Choi for the degree of Doctor of Philosophyin Computer Science presented on February 6, 1992. Title: Active Object Systems Redacted for Privacy Abstract approved. v '" Toshimi Minoura An active object system isa transition-based object-oriented system suitable for the design of various concurrentsystems. An AOS consists of a collection of interacting objects, where the behavior of eachobject is determined by the transition statements provided in the class of that object.A transition statement is a condition-action pair, an equational assignmentstatement, or an event routine. The transition statements provided for eachobject can access, besides the state of that object, the states of the other objectsknown to it through its interface variables. Interface variablesare bound to objects when objects are instantiated so that desired connections among objects are established. The major benefit of the AOS approach is thatan active system can be hierarchically composed from its active software componentsas if it were a hardware system. An AOS provides better encapsulation andmore flexible communication protocols than ordinary object oriented systems, since control withinan AOS is localized. ©Copyright by Sungwoon Choi February 6, 1992 All Rights Reserved Active Object Systems by Sungwoon Choi A THESIS submitted to Oregon State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy Completed February 6, 1992 Commencement June 1992 APPROVED: Redacted for Privacy Professor of Computer Science in charge ofmajor Redacted for Privacy Head of Department of Computer Science Redacted for Privacy Dean of Gradu to School Or Date thesis presented February 6, 1992 Typed by Sungwoon Choi for Sungwoon Choi To my wife Yejung ACKNOWLEDGEMENTS I would like to express my sincere gratitude tomy major professor, Dr.
    [Show full text]
  • Thread Management for High Performance Database Systems - Design and Implementation
    Nr.: FIN-003-2018 Thread Management for High Performance Database Systems - Design and Implementation Robert Jendersie, Johannes Wuensche, Johann Wagner, Marten Wallewein-Eising, Marcus Pinnecke, Gunter Saake Arbeitsgruppe Database and Software Engineering Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Nr.: FIN-003-2018 Thread Management for High Performance Database Systems - Design and Implementation Robert Jendersie, Johannes Wuensche, Johann Wagner, Marten Wallewein-Eising, Marcus Pinnecke, Gunter Saake Arbeitsgruppe Database and Software Engineering Technical report (Internet) Elektronische Zeitschriftenreihe der Fakultät für Informatik der Otto-von-Guericke-Universität Magdeburg ISSN 1869-5078 Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Impressum (§ 5 TMG) Herausgeber: Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Der Dekan Verantwortlich für diese Ausgabe: Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Marcus Pinnecke Postfach 4120 39016 Magdeburg E-Mail: [email protected] http://www.cs.uni-magdeburg.de/Technical_reports.html Technical report (Internet) ISSN 1869-5078 Redaktionsschluss: 21.08.2018 Bezug: Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Dekanat Thread Management for High Performance Database Systems - Design and Implementation Technical Report Robert Jendersie1, Johannes Wuensche2, Johann Wagner1, Marten Wallewein-Eising2, Marcus Pinnecke1, and Gunter Saake1 Database and Software Engineering Group, Otto-von-Guericke University
    [Show full text]
  • An Efficient Implementation of Guard-Based Synchronization for an Object-Oriented Programming Language an Efficient Implementation of Guard-Based
    AN EFFICIENT IMPLEMENTATION OF GUARD-BASED SYNCHRONIZATION FOR AN OBJECT-ORIENTED PROGRAMMING LANGUAGE AN EFFICIENT IMPLEMENTATION OF GUARD-BASED SYNCHRONIZATION FOR AN OBJECT-ORIENTED PROGRAMMING LANGUAGE By SHUCAI YAO, M.Sc., B.Sc. A Thesis Submitted to the Department of Computing and Software and the School of Graduate Studies of McMaster University in Partial Fulfilment of the Requirements for the Degree of Doctor of Philosophy McMaster University c Copyright by Shucai Yao, July 2020 Doctor of Philosophy (2020) McMaster University (Computing and Software) Hamilton, Ontario, Canada TITLE: An Efficient Implementation of Guard-Based Synchro- nization for an Object-Oriented Programming Language AUTHOR: Shucai Yao M.Sc., (Computer Science) University of Science and Technology Beijing B.Sc., (Computer Science) University of Science and Technology Beijing SUPERVISOR: Dr. Emil Sekerinski, Dr. William M. Farmer NUMBER OF PAGES: xvii,167 ii To my beloved family Abstract Object-oriented programming has had a significant impact on software development because it provides programmers with a clear structure of a large system. It encap- sulates data and operations into objects, groups objects into classes and dynamically binds operations to program code. With the emergence of multi-core processors, application developers have to explore concurrent programming to take full advan- tage of multi-core technology. However, when it comes to concurrent programming, object-oriented programming remains elusive as a useful programming tool. Most object-oriented programming languages do have some extensions for con- currency, but concurrency is implemented independently of objects: for example, concurrency in Java is managed separately with the Thread object. We employ a programming model called Lime that combines action systems tightly with object- oriented programming and implements concurrency by extending classes with actions and guarded methods.
    [Show full text]
  • Concurrency & Parallel Programming Patterns
    Concurrency & Parallel programming patterns Evgeny Gavrin Outline 1. Concurrency vs Parallelism 2. Patterns by groups 3. Detailed overview of parallel patterns 4. Summary 5. Proposal for language Concurrency vs Parallelism ● Parallelism is the simultaneous execution of computations “doing lots of things at once” ● Concurrency is the composition of independently execution processes “dealing with lots of thing at once” Patterns by groups Architectural Patterns These patterns define the overall architecture for a program: ● Pipe-and-filter: view the program as filters (pipeline stages) connected by pipes (channels). Data flows through the filters to take input and transform into output. ● Agent and Repository: a collection of autonomous agents update state managed on their behalf in a central repository. ● Process control: the program is structured analogously to a process control pipeline with monitors and actuators moderating feedback loops and a pipeline of processing stages. ● Event based implicit invocation: The program is a collection of agents that post events they watch for and issue events for other agents. The architecture enforces a high level abstraction so invocation of an agent is implicit; i.e. not hardwired to a specific controlling agent. ● Model-view-controller: An architecture with a central model for the state of the program, a controller that manages the state and one or more agents that export views of the model appropriate to different uses of the model. ● Bulk Iterative (AKA bulk synchronous): A program that proceeds iteratively … update state, check against a termination condition, complete coordination, and proceed to the next iteration. ● Map reduce: the program is represented in terms of two classes of functions.
    [Show full text]
  • Model Checking Multithreaded Programs With
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Illinois Digital Environment for Access to Learning and Scholarship Repository Model Checking Multithreaded Programs with Asynchronous Atomic Methods Koushik Sen and Mahesh Viswanathan Department of Computer Science, University of Illinois at Urbana-Champaign. {ksen,vmahesh}@uiuc.edu Abstract. In order to make multithreaded programming manageable, program- mers often follow a design principle where they break the problem into tasks which are then solved asynchronously and concurrently on different threads. This paper investigates the problem of model checking programs that follow this id- iom. We present a programming language SPL that encapsulates this design pat- tern. SPL extends simplified form of sequential Java to which we add the ca- pability of making asynchronous method invocations in addition to the standard synchronous method calls and the ability to execute asynchronous methods in threads atomically and concurrently. Our main result shows that the control state reachability problem for finite SPL programs is decidable. Therefore, such mul- tithreaded programs can be model checked using the counter-example guided abstraction-refinement framework. 1 Introduction Multithreaded programming is often used in software as it leads to reduced latency, improved response times of interactive applications, and more optimal use of process- ing power. Multithreaded programming also allows an application to progress even if one thread is blocked for an I/O operation. However, writing correct programs that use multiple threads is notoriously difficult, especially in the presence of a shared muta- ble memory. Since threads can interleave, there can be unintended interference through concurrent access of shared data and result in software errors due to data race and atom- icity violations.
    [Show full text]
  • Lecture 26: Creational Patterns
    Creational Patterns CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 26 — 11/29/2012 © Kenneth M. Anderson, 2012 1 Goals of the Lecture • Cover material from Chapters 20-22 of the Textbook • Lessons from Design Patterns: Factories • Singleton Pattern • Object Pool Pattern • Also discuss • Builder Pattern • Lazy Instantiation © Kenneth M. Anderson, 2012 2 Pattern Classification • The Gang of Four classified patterns in three ways • The behavioral patterns are used to manage variation in behaviors (think Strategy pattern) • The structural patterns are useful to integrate existing code into new object-oriented designs (think Bridge) • The creational patterns are used to create objects • Abstract Factory, Builder, Factory Method, Prototype & Singleton © Kenneth M. Anderson, 2012 3 Factories & Their Role in OO Design • It is important to manage the creation of objects • Code that mixes object creation with the use of objects can become quickly non-cohesive • A system may have to deal with a variety of different contexts • with each context requiring a different set of objects • In design patterns, the context determines which concrete implementations need to be present © Kenneth M. Anderson, 2012 4 Factories & Their Role in OO Design • The code to determine the current context, and thus which objects to instantiate, can become complex • with many different conditional statements • If you mix this type of code with the use of the instantiated objects, your code becomes cluttered • often the use scenarios can happen in a few lines of code • if combined with creational code, the operational code gets buried behind the creational code © Kenneth M. Anderson, 2012 5 Factories provide Cohesion • The use of factories can address these issues • The conditional code can be hidden within them • pass in the parameters associated with the current context • and get back the objects you need for the situation • Then use those objects to get your work done • Factories concern themselves just with creation, letting your code focus on other things © Kenneth M.
    [Show full text]
  • Active Object
    Active Object an Object Behavioral Pattern for Concurrent Programming R. Greg Lavender Douglas C. Schmidt [email protected] [email protected] ISODE Consortium Inc. Department of Computer Science Austin, TX Washington University, St. Louis An earlier version of this paper appeared in a chapter in the book ªPattern Languages of Program Design 2º ISBN 0-201-89527-7, edited by John Vlissides, Jim Coplien, and Norm Kerth published by Addison-Wesley, 1996. : Output : Input Handler Handler : Routing Table : Message Abstract Queue This paper describes the Active Object pattern, which decou- 3: enqueue(msg) ples method execution from method invocation in order to : Output 2: find_route(msg) simplify synchronized access to a shared resource by meth- Handler ods invoked in different threads of control. The Active Object : Message : Input pattern allows one or more independent threads of execution Queue Handler 1: recv(msg) to interleave their access to data modeled as a single ob- ject. A broad class of producer/consumer and reader/writer OUTGOING OUTGOING MESSAGES GATEWAY problems are well-suited to this model of concurrency. This MESSAGES pattern is commonly used in distributed systems requiring INCOMING INCOMING multi-threaded servers. In addition,client applications (such MESSAGES MESSAGES as windowing systems and network browsers), are increas- DST DST ingly employing active objects to simplify concurrent, asyn- SRC SRC chronous network operations. 1 Intent Figure 1: Connection-Oriented Gateway The Active Object pattern decouples method execution from method invocation in order to simplify synchronized access to a shared resource by methods invoked in different threads [2]. Sources and destinationscommunicate with the Gateway of control.
    [Show full text]
  • An Enhanced Thread Synchronization Mechanism for Java
    SOFTWARE—PRACTICE AND EXPERIENCE Softw. Pract. Exper. 2001; 31:667–695 (DOI: 10.1002/spe.383) An enhanced thread synchronization mechanism for Java Hsin-Ta Chiao and Shyan-Ming Yuan∗,† Department of Computer and Information Science, National Chiao Tung University, 1001 Ta Hsueh Road, Hsinchu 300, Taiwan SUMMARY The thread synchronization mechanism of Java is derived from Hoare’s monitor concept. In the authors’ view, however, it is over simplified and suffers the following four drawbacks. First, it belongs to a category of no-priority monitor, the design of which, as reported in the literature on concurrent programming, is not well rated. Second, it offers only one condition queue. Where more than one long-term synchronization event is required, this restriction both degrades performance and further complicates the ordering problems that a no-priority monitor presents. Third, it lacks the support for building more elaborate scheduling programs. Fourth, during nested monitor invocations, deadlock may occur. In this paper, we first analyze these drawbacks in depth before proceeding to present our own proposal, which is a new monitor-based thread synchronization mechanism that we term EMonitor. This mechanism is implemented solely by Java, thus avoiding the need for any modification to the underlying Java Virtual Machine. A preprocessor is employed to translate the EMonitor syntax into the pure Java codes that invoke the EMonitor class libraries. We conclude with a comparison of the performance of the two monitors and allow the experimental results to demonstrate that, in most cases, replacing the Java version with the EMonitor version for developing concurrent Java objects is perfectly feasible.
    [Show full text]
  • Designing for Performance: Concurrency and Parallelism COS 518: Computer Systems Fall 2015
    Designing for Performance: Concurrency and Parallelism COS 518: Computer Systems Fall 2015 Logan Stafman Adapted from slides by Mike Freedman 2 Definitions • Concurrency: – Execution of two or more tasks overlap in time. • Parallelism: – Execution of two or more tasks occurs simultaneous. Concurrency without 3 parallelism? • Parts of tasks interact with other subsystem – Network I/O, Disk I/O, GPU, ... • Other task can be scheduled while first waits on subsystem’s response Concurrency without parrallelism? Source: bjoor.me 5 Scheduling for fairness • On time-sharing system also want to schedule between tasks, even if one not blocking – Otherwise, certain tasks can keep processing – Leads to starvation of other tasks • Preemptive scheduling – Interrupt processing of tasks to process another task (why with tasks and not network packets?) • Many scheduling disciplines – FIFO, Shortest Remaining Time, Strict Priority, Round-Robin Preemptive Scheduling Source: embeddedlinux.org.cn Concurrency with 7 parallelism • Execute code concurrently across CPUs – Clusters – Cores • CPU parallelism different from distributed systems as ready availability to shared memory – Yet to avoid difference between parallelism b/w local and remote cores, many apps just use message passing between both (like HPC’s use of MPI) Symmetric Multiprocessors 8 (SMPs) Non-Uniform Memory Architectures 9 (NUMA) 10 Pros/Cons of NUMA • Pros Applications split between different processors can share memory close to hardware Reduced bus bandwidth usage • Cons Must ensure applications sharing memory are run on processors sharing memory 11 Forms of task parallelism • Processes – Isolated process address space – Higher overhead between switching processes • Threads – Concurrency within process – Shared address space – Three forms • Kernel threads (1:1) : Kernel support, can leverage hardware parallelism • User threads (N:1): Thread library in system runtime, fastest context switching, but cannot benefit from multi- threaded/proc hardware • Hybrid (M:N): Schedule M user threads on N kernel threads.
    [Show full text]
  • Assessment of Barrier Implementations for Fine-Grain Parallel Regions on Current Multi-Core Architectures
    Assessment of Barrier Implementations for Fine-Grain Parallel Regions on Current Multi-core Architectures Simon A. Berger and Alexandros Stamatakis The Exelixis Lab Department of Computer Science Technische Universitat¨ Munchen¨ Boltzmannstr. 3, D-85748 Garching b. Munchen,¨ Germany Email: [email protected], [email protected] WWW: http://wwwkramer.in.tum.de/exelixis/ time Abstract—Barrier performance for synchronizing threads master thread on current multi-core systems can be critical for scientific applications that traverse a large number of relatively small parallel regions, that is, that exhibit an unfavorable com- fork putation to synchronization ratio. By means of a synthetic and a real-world benchmark we assess 4 alternative barrier worker threads parallel region implementations on 7 current multi-core systems with 2 up to join 32 cores. We find that, barrier performance is application- and data-specific with respect to cache utilization, but that a rather fork na¨ıve lock-free barrier implementation yields good results across all applications and multi-core systems tested. We also worker threads parallel region assess distinct implementations of reduction operations that join are computed in conjunction with the barriers. The synthetic and real-world benchmarks are made available as open-source code for further testing. Keywords-barriers; multi-cores; threads; RAxML Figure 1. Classic fork-join paradigm. I. INTRODUCTION The performance of barriers for synchronizing threads on modern general-purpose multi-core systems is of vital In addition, we analyze the efficient implementation of importance for the efficiency of scientific codes. Barrier reduction operations (sums over the double values produced performance can become critical, if a scientific code exhibits by each for-loop iteration), that are frequently required a high number of relatively small (with respect to the in conjunction with barriers.
    [Show full text]
  • MULTI-ACTIVE OBJECTS and THEIR APPLICATIONS 1. Introduction
    Logical Methods in Computer Science Vol. 13(4:12)2017, pp. 1–41 Submitted Nov. 01, 2016 https://lmcs.episciences.org/ Published Nov. 21, 2017 MULTI-ACTIVE OBJECTS AND THEIR APPLICATIONS LUDOVIC HENRIO AND JUSTINE ROCHAS Universit´eC^oted'Azur, CNRS, I3S, France e-mail address: [email protected], [email protected] Abstract. In order to tackle the development of concurrent and distributed systems, the active object programming model provides a high-level abstraction to program concurrent behaviours. There exists already a variety of active object frameworks targeted at a large range of application domains: modelling, verification, efficient execution. However, among these frameworks, very few consider a multi-threaded execution of active objects. Introducing controlled parallelism within active objects enables overcoming some of their limitations. In this paper, we present a complete framework around the multi-active object programming model. We present it through ProActive, the Java library that offers multi-active objects, and through MultiASP, the programming language that allows the formalisation of our developments. We then show how to compile an active object language with cooperative multi-threading into multi-active objects. This paper also presents different use cases and the development support to illustrate the practical usability of our language. Formalisation of our work provides the programmer with guarantees on the behaviour of the multi-active object programming model and of the compiler. 1. Introduction Systems and applications nowadays run in a concurrent and distributed manner. In general, existing programming models and languages lack adequate abstractions for handling the concurrency of parallel programs and for writing distributed applications.
    [Show full text]
  • Migrating Thread-Based Intentional Concurrent Programming to a Task-Based Paradigm
    University of New Hampshire University of New Hampshire Scholars' Repository Master's Theses and Capstones Student Scholarship Fall 2016 MIGRATING THREAD-BASED INTENTIONAL CONCURRENT PROGRAMMING TO A TASK-BASED PARADIGM Seth Adam Hager University of New Hampshire, Durham Follow this and additional works at: https://scholars.unh.edu/thesis Recommended Citation Hager, Seth Adam, "MIGRATING THREAD-BASED INTENTIONAL CONCURRENT PROGRAMMING TO A TASK-BASED PARADIGM" (2016). Master's Theses and Capstones. 885. https://scholars.unh.edu/thesis/885 This Thesis is brought to you for free and open access by the Student Scholarship at University of New Hampshire Scholars' Repository. It has been accepted for inclusion in Master's Theses and Capstones by an authorized administrator of University of New Hampshire Scholars' Repository. For more information, please contact [email protected]. MIGRATING THREAD-BASED INTENTIONAL CONCURRENT PROGRAMMING TO A TASK-BASED PARADIGM BY Seth Hager B.M., University of Massachusetts Lowell, 2004 THESIS Submitted to the University of New Hampshire in Partial Fulfillment of the Requirements for the Degree of Master of Science in Computer Science September 2016 This thesis has been examined and approved in partial fulfillment of the requirements for the degree of Master of Science in Computer Science by: Thesis director, Philip J. Hatcher, Professor of Computer Science Michel H. Charpentier, Associate Professor of Computer Science R. Daniel Bergeron, Professor of Computer Science August 16th, 2016 Original approval signatures are on file with the University of New Hampshire Graduate School. DEDICATION For Lily and Jacob. iii ACKNOWLEDGMENTS I would like to thank the members of my committee for all of their time and effort.
    [Show full text]