DOCSLIB.ORG

A Programming Model and Language for Concurrent and Distributed Object-Oriented Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

A Programming Model and Language for Concurrent and Distributed Object-Oriented Systems Jan Schäfer Vom Fachbereich Informatik der Technischen Universität Kaiserslautern zur Verleihung des akademischen Grades Doktor-Ingenieur (Dr.-Ing.) genehmigte Dissertation Datum der wissenschaftlichen Aussprache: 5. November 2010 Dekan: Prof. Dr. Karsten Berns Vorsitzender der Promotionskommission: Prof. Dr. Reinhard Gotzhein Erster Berichterstatter: Prof. Dr. Arnd Poetzsch-Heffter Zweiter Berichterstatter: Prof. Dr. Einar Broch Johnsen D 386 Cover image: http://www.flickr.com/photos/handersongomes/2471526525/ (c) Handerson Gomes under the Creative Commons Licence (CC BY 2.0) http://creativecommons.org/licenses/by/2.0/deed.en To my family Abstract The wide availability of multi-core processors and the ubiquitous presence of the Internet lead to new challenges in software design and implementation. Software has to be written in a parallelizable way to profit from multiple cores. Interaction with distributed Internet services requires coping with message delays and network failures. These challenges reach application domains, like desktop applications, which have been mainly written in a sequential way in the past. The concurrency model of mainstream object-oriented programming languages is based preemptively scheduled threads, which concurrently work on a shared object-heap. This programming model is highly prone to race conditions, i.e., hard to find concurrency-related errors that are not easily reproducible. To synchronize threads and prevent data races, operating system mechanisms like locks have to be used. Experience shows that this programming model is too difficult for most programmers, is not very modular, and is not well suited for the behavioral description of software components. Furthermore, the thread-based model is not appropriate for realizing distributed systems, due to its inherent synchronous communication model. This thesis proposes a novel programming model for concurrent and distributed, object-oriented systems. The so-called cobox model generalizes the concept of active objects to concurrent, object-oriented runtime components, called coboxes. CoBoxes have their own, local object-heap, which cannot be directly accessed by other coboxes. CoBoxes communicate by asynchronous method calls with standard objects as targets, where multiple objects of a single cobox can be used for interaction. Computations inside coboxes happen via standard object-oriented programming, combined with co- operative multi-tasking. The thesis at hand presents a formalization of the semantics of the cobox model in a core calculus. The calculus is proved type-sound and several additional properties are formally covered. The dynamic semantics of the core calcu- lus is implemented in the rewriting logic framework Maude. In addition, the cobox model is realized in a practical programming language called JCoBox, which extends standard sequential Java. JCoBox is implemented by a Java compiler extension as well as a JVM bytecode rewriter. The performance of JCoBox can compete with state-of-the-art actor implementations for the JVM. The practicability of the proposed programming model and language is evaluated by the design and implementation of several concurrent applications. Zusammenfassung Die breite Verfügbarkeit von Mehrkernprozessoren und die Allgegenwärtigkeit des Internets führt zu neuen Herausforderungen für das Design und die Implemen- tierung von Software. Diese Herausforderungen erreichen Softwaredomänen, wie Desktop-Anwendungen, in denen in der Vergangenheit hauptsächlich sequenziell und rechnerlokal programmiert wurde. Damit Software von mehreren Kernen profi- tieren kann, muss sie nebenläufig geschrieben werden. Die Interaktion mit verteilten Internet-Services verlangt die Behandlung von Nachrichtenverzögerungen und Netzw- erkausfällen. Das Nebenläufigkeitsmodell von etablierten objektorientierten Program- miersprachen bietet hier dem Programmierer wenig Unterstützung. Es basiert in der Regel auf preemptiven Threads, die über gemeinsamen Speicher kommunizieren und Daten austauschen. Dieses Programmiermodell ist hochgradig anfällig für Wettlaufsi- tuationen, die zu schwer auffindbaren Nebenläufigkeitsfehler führen. Die Erfahrung zeigt, dass dieses Programmiermodell zu schwierig für die meisten Softwareentwick- ler und -entwicklerinnen ist. Es ist des weiteren nicht besonders modular und nicht gut geeignet für die verteilte Programmierung, wegen ihres inhärenten, synchronen Kommunikationsmodells. Die vorliegende Arbeit schlägt ein neues Programmiermodell für nebenläufige und verteilte, objektorientierte Systeme vor. Das sogenannte CoBox-Modell verallgemein- ert das Konzept der Aktiven Objekte hin zu objektorientierten Laufzeitkomponen- ten, genannt CoBoxen. CoBoxen besitzen ihren eigenen, lokalen Objekt-Speicher, welcher von anderen CoBoxen nicht direkt zugreifbar ist. CoBoxen kommunizieren mittels asynchroner Methodenaufrufe, die sich an normale Objekte richten, wobei mehrere Objekte einer einzelnen CoBox zur Interaktion verwendet werden können. Berechnungen innerhalb einer CoBox geschehen mittels normaler objektorientierter Programmierung, kombiniert mit kooperativen Multi-Tasking. Die vorliegende Arbeit präsentiert eine Formalisierung der Semantik des CoBox-Modells in einem Kernkalkül. Das Kalkül ist als typsicher bewiesen und weitere Eigenschaften sind formal behandelt. Die dynamische Semantik des Kalküls ist in dem Rewriting-Logik-Framework Maude implementiert. Eine Java-Erweiterung namens JCoBox zeigt wie das CoBox-Modell in der Praxis umgesetzt werden kann. JCoBox kann sowohl durch einen Kompiler als auch durch Bytecode-Rewriting in standard JVM-Bytecode transformiert werden. Die Geschwindigkeit der JCoBox-Implementierung ist vergleichbar mit anderen moder- nen Aktor-Implementierungen für die JVM. Die Praktikabilität des vorgeschlagenen Programmiermodells und der Sprachumsetzung ist evaluiert durch das Design und die Implementierung von mehreren nebenläufigen Anwendungen. Acknowledgments First of all I thank my supervisor Prof. Dr. Arnd Poetzsch-Heffter. Besides the financial aspect of organizing the funding of my research, he had given me much freedom in the choice of my research and gave me constant support and motivation. I also thank Prof. Dr. Einar Broch Johnsen who reviewed this thesis as the second reviewer and Prof. Dr. Reinhard Gotzhein for chairing the doctoral committee. I thank all my past and current colleagues of the Software Technology Group for many joyful days and fruitful discussions. It has always been a pleasure to work in this group. Concerning this thesis, I thank, in particular, Yannick Welsch for greatly supporting me during the last months of the dissertation writing by relieving me of much of the daily project work. In addition, I thank Yannick for a thorough proof reading of this thesis. For further proof reading I thank Ilham Kurnia and Jean-Marie Gaillourdet. I thank all students, who participated in the cobox journey. In particular, I thank Peter Wortmann for his Scala realization of the cobox model. His work sharped my view on the interplay between promises, futures, and transfer objects. In addition, he revealed several bugs in the JCoBox implementation and several ideas from his task scheduler implementation greatly improved the performance of the JCoBox scheduler. I also thank Alexander Worret, who was the first student who used JCoBox for a larger case study. I thank Arda Subasi, who initiated the bytecode rewriting tool for JCoBox and also helped with the performance evaluation. I thank the authors of all the open source software that I used for doing my research, which are far too many to name here. I also thank Handerson Gomes who made the beautiful cover picture available under a free license. I am very thankful to my parents-in-law Larissa and Eduard for taking care of our daughter in the last month before the finishing of this thesis. Without their support, it would have been much more difficult for me to finish the thesis in time. I thank my parents Marion and Eugen for everything they did for me. I thank my daughter Eline Jolie. With her, no day is like the other, and she always reminds me that there are much more important things in life than computer science. Last but not least, I thank my wife Ekaterina, who always believes in me. Contents 1 Introduction1 1.1 Multi-Threaded Object-Oriented Programming Revisited.........2 1.1.1 Objects...................................2 1.1.2 Sequential Programming Model....................3 1.1.3 Thread-Based Concurrency.......................4 1.2 Active Objects...................................6 1.3 Object-Oriented Components..........................7 1.4 Goals, Contributions, and Outline.......................9 1.4.1 Goals....................................9 1.4.2 Contributions...............................9 1.4.3 Outline................................... 10 2 The CoBox Model 13 2.1 Motivating Example............................... 13 2.1.1 Requirements............................... 13 2.1.2 Object-Oriented Design......................... 14 2.1.3 Thread-Based Implementation.................... 15 2.2 Basic Concepts................................... 16 2.2.1 CoBoxes and Objects.......................... 16 2.2.2 Tasks.................................... 17 2.2.3 Asynchronous Communication.................... 19 2.2.4 Designing the Chat Example...................... 20 2.3 Synchronization and Data Exchange..................... 21 2.3.1 Futures..................................
Recommended publications
  • Building Great Interfaces with OOABL

    Building Great Interfaces with OOABL

    Building great Interfaces with OOABL Mike Fechner Director Übersicht © 2018 Consultingwerk Ltd. All rights reserved. 2 Übersicht © 2018 Consultingwerk Ltd. All rights reserved. 3 Übersicht Consultingwerk Software Services Ltd. ▪ Independent IT consulting organization ▪ Focusing on OpenEdge and related technology ▪ Located in Cologne, Germany, subsidiaries in UK and Romania ▪ Customers in Europe, North America, Australia and South Africa ▪ Vendor of developer tools and consulting services ▪ Specialized in GUI for .NET, Angular, OO, Software Architecture, Application Integration ▪ Experts in OpenEdge Application Modernization © 2018 Consultingwerk Ltd. All rights reserved. 4 Übersicht Mike Fechner ▪ Director, Lead Modernization Architect and Product Manager of the SmartComponent Library and WinKit ▪ Specialized on object oriented design, software architecture, desktop user interfaces and web technologies ▪ 28 years of Progress experience (V5 … OE11) ▪ Active member of the OpenEdge community ▪ Frequent speaker at OpenEdge related conferences around the world © 2018 Consultingwerk Ltd. All rights reserved. 5 Übersicht Agenda ▪ Introduction ▪ Interface vs. Implementation ▪ Enums ▪ Value or Parameter Objects ▪ Fluent Interfaces ▪ Builders ▪ Strong Typed Dynamic Query Interfaces ▪ Factories ▪ Facades and Decorators © 2018 Consultingwerk Ltd. All rights reserved. 6 Übersicht Introduction ▪ Object oriented (ABL) programming is more than just a bunch of new syntax elements ▪ It’s easy to continue producing procedural spaghetti code in classes ▪
  • Active Object Systems Redacted for Privacy Abstract Approved

    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.
  • Justice XML Data Model Technical Overview

    Justice XML Data Model Technical Overview

    Justice XML Data Model Technical Overview April 2003 WhyWhy JusticeJustice XMLXML DataData ModelModel VersionVersion 3.0?3.0? • Aligned with standards (some were not available to RDD) • Model-based Æ consistent • Requirements-based – data elements, processes, and documents • Object-oriented Æ efficient extension and reuse • Expanded domain (courts, corrections, and juvenile) • Extensions to activity objects/processes • Relationships (to improve exchange information context) • Can evolve/advance with emerging technology (RDF/OWL) • Model provides the basis for an XML component registry that can provide • Searching/browsing components and metadata • Assistance for schema development/generation • Reference/cache XML schemas for validation • Interface (via standard specs) to external XML registries April 2003 DesignDesign PrinciplesPrinciples • Design and synthesize a common set of reusable, extensible data components for a Justice XML Data Dictionary (JXDD) that facilitates standard information exchange in XML. • Generalize JXDD for the justice and public safety communities – do NOT target specific applications. • Provide reference-able schema components primarily for schema developers. • JXDD and schema will evolve and, therefore, facilitate change and extension. • Best extension methods should minimize impact on prior schema and code investments. • Implement and represent domain relationships so they are globally understood. • Technical dependencies in requirements, solutions, and the time constraints of national priorities and demands
  • Object Query Language Reference Version: Itop 1.0

    Object Query Language Reference Version: Itop 1.0

    Object Query Language Reference Version: Itop 1.0 Overview OQL aims at defining a subset of the data in a natural language, while hiding the complexity of the data model and benefit of the power of the object model (encapsulation, inheritance). Its syntax sticks to the syntax of SQL, and its grammar is a subset of SQL. As of now, only SELECT statements have been implemented. Such a statement do return objects of the expected class. The result will be used by programmatic means (to develop an API like ITOp). A famous example: the library Starter SELECT Book Do return any book existing in the Database. No need to specify the expected columns as we would do in a SQL SELECT clause: OQL do return plain objects. Join classes together I would like to list all books written by someone whose name starts with `Camus' SELECT Book JOIN Artist ON Book.written_by = Artist.id WHERE Artist.name LIKE 'Camus%' Note that there is no need to specify wether the JOIN is an INNER JOIN, or LEFT JOIN. This is well-known in the data model. The OQL engine will in turn create a SQL queries based on the relevant option, but we do not want to care about it, do we? © Combodo 2010 1 Now, you may consider that the name of the author of a book is of importance. This is the case if should be displayed anytime you will list a set of books, or if it is an important key to search for. Then you have the option to change the data model, and define the name of the author as an external field.
  • Functional Javascript

    Functional Javascript

    www.it-ebooks.info www.it-ebooks.info Functional JavaScript Michael Fogus www.it-ebooks.info Functional JavaScript by Michael Fogus Copyright © 2013 Michael Fogus. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/ institutional sales department: 800-998-9938 or [email protected]. Editor: Mary Treseler Indexer: Judith McConville Production Editor: Melanie Yarbrough Cover Designer: Karen Montgomery Copyeditor: Jasmine Kwityn Interior Designer: David Futato Proofreader: Jilly Gagnon Illustrator: Robert Romano May 2013: First Edition Revision History for the First Edition: 2013-05-24: First release See http://oreilly.com/catalog/errata.csp?isbn=9781449360726 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Functional JavaScript, the image of an eider duck, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trade‐ mark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
  • Automating Testing with Autofixture, Xunit.Net & Specflow

    Automating Testing with Autofixture, Xunit.Net & Specflow

    Design Patterns Michael Heitland Oct 2015 Creational Patterns • Abstract Factory • Builder • Factory Method • Object Pool* • Prototype • Simple Factory* • Singleton (* this pattern got added later by others) Structural Patterns ● Adapter ● Bridge ● Composite ● Decorator ● Facade ● Flyweight ● Proxy Behavioural Patterns 1 ● Chain of Responsibility ● Command ● Interpreter ● Iterator ● Mediator ● Memento Behavioural Patterns 2 ● Null Object * ● Observer ● State ● Strategy ● Template Method ● Visitor Initial Acronym Concept Single responsibility principle: A class should have only a single responsibility (i.e. only one potential change in the S SRP software's specification should be able to affect the specification of the class) Open/closed principle: “Software entities … should be open O OCP for extension, but closed for modification.” Liskov substitution principle: “Objects in a program should be L LSP replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract. Interface segregation principle: “Many client-specific I ISP interfaces are better than one general-purpose interface.”[8] Dependency inversion principle: One should “Depend upon D DIP Abstractions. Do not depend upon concretions.”[8] Creational Patterns Simple Factory* Encapsulating object creation. Clients will use object interfaces. Abstract Factory Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Inject the factory into the object. Dependency Inversion Principle Depend upon abstractions. Do not depend upon concrete classes. Our high-level components should not depend on our low-level components; rather, they should both depend on abstractions. Builder Separate the construction of a complex object from its implementation so that the two can vary independently. The same construction process can create different representations.
  • 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

    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.
  • Composable Concurrency Models

    Composable Concurrency Models

    Composable Concurrency Models Dan Stelljes Division of Science and Mathematics University of Minnesota, Morris Morris, Minnesota, USA 56267 [email protected] ABSTRACT Given that an application is likely to make use of more The need to manage concurrent operations in applications than one concurrency model, programmers would prefer that has led to the development of a variety of concurrency mod- different types of models could safely interact. However, dif- els. Modern programming languages generally provide sev- ferent models do not necessarily work well together, nor are eral concurrency models to serve different requirements, and they designed to. Recent work has attempted to identify programmers benefit from being able to use them in tandem. common \building blocks" that could be used to compose We discuss challenges surrounding concurrent programming a variety of models, possibly eliminating subtle problems and examine situations in which conflicts between models when different models interact and allowing models to be can occur. Additionally, we describe attempts to identify represented at lower levels without resorting to rough ap- features of common concurrency models and develop lower- proximations [9, 11, 12]. level abstractions capable of supporting a variety of models. 2. BACKGROUND 1. INTRODUCTION In a concurrent program, the history of operations may Most interactive computer programs depend on concur- not be the same for every execution. An entirely sequen- rency, the ability to perform different tasks at the same tial program could be proved to be correct by showing that time. A web browser, for instance, might at any point be its history (that is, the sequence in which its operations are rendering documents in multiple tabs, transferring files, and performed) always yields a correct result.
  • Incorparating the Actor Model Into SCIVE on an Abstract Semantic Level

    Incorparating the Actor Model Into SCIVE on an Abstract Semantic Level

    Incorparating the Actor Model into SCIVE on an Abstract Semantic Level Christian Frohlich¨ ∗ Marc E. Latoschik† AI and VR Group, Bielefeld University AI and VR Group, Bielefeld University. ABSTRACT Since visual perception is very important for generating immer- sive environments, most VR applications focus on the graphical This paper illustrates the temporal synchronization and process flow simulation output. Tools like OpenGL Performer, Open Inven- facilities of a real-time simulation system which is based on the ac- tor [12], Open Scene Graph, OpenSG [11] or the VRML successor tor model. The requirements of such systems are compared against X3D [8] are based upon a hierarchical scene graph structure, which the actor model’s basic features and structures. The paper describes allows for complex rendering tasks. Extension mechanisms like how a modular architecture benefits from the actor model on the field routing or rapid prototyping via scipting interfaces allow for module level and points out how the actor model enhances paral- new customized node types and interconnected application graphs. lelism and concurrency even down to the entity level. The actor idea is incorporated into a novel simulation core for intelligent vir- Purpose-built VR application frameworks adopt and extend these mechanisms, by adding in- and output customization, see e.g. tual environments (SCIVE). SCIVE supports well-known and es- TM tablished Virtual Reality paradigms like the scene graph metaphor, Lightning [4], Avango [13], VR Juggler [3] or the CAVELib . field routing concepts etc. In addition, SCIVE provides an explicit Also network distribution paradigms are often integrated to enable semantic representation of its internals as well as of the specific distributed rendering on a cluster architecture, as can be seen in virtual environments’ contents.
  • Foundations of the Unified Modeling Language

    Foundations of the Unified Modeling Language

    Foundations of the Unified Modeling Language. CLARK, Anthony <http://orcid.org/0000-0003-3167-0739> and EVANS, Andy Available from Sheffield Hallam University Research Archive (SHURA) at: http://shura.shu.ac.uk/11889/ This document is the author deposited version. You are advised to consult the publisher's version if you wish to cite from it. Published version CLARK, Anthony and EVANS, Andy (1997). Foundations of the Unified Modeling Language. In: 2nd BCS-FACS Northern Formal Methods Workshop., Ilkley, UK, 14- 15 July 1997. Springer. Copyright and re-use policy See http://shura.shu.ac.uk/information.html Sheffield Hallam University Research Archive http://shura.shu.ac.uk Foundations of the Unified Modeling Language Tony Clark, Andy Evans Formal Methods Group, Department of Computing, University of Bradford, UK Abstract Object-oriented analysis and design is an increasingly popular software development method. The Unified Modeling Language (UML) has recently been proposed as a standard language for expressing object-oriented designs. Unfor- tunately, in its present form the UML lacks precisely defined semantics. This means that it is difficult to determine whether a design is consistent, whether a design modification is correct and whether a program correctly implements a design. Formal methods provide the rigor which is lacking in object-oriented design notations. This provision is often at the expense of clarity of exposition for the non-expert. Formal methods aim to use mathematical techniques in order to allow software development activities to be precisely defined, checked and ultimately automated. This paper aims to present an overview of work being undertaken to provide (a sub-set of) the UML with formal semantics.
  • Reactive Async: Expressive Deterministic Concurrency

    Reactive Async: Expressive Deterministic Concurrency

    Reactive Async: Expressive Deterministic Concurrency Philipp Haller Simon Geries Michael Eichberg Guido Salvaneschi KTH Royal Institute of Technology, Sweden TU Darmstadt, Germany [email protected] feichberg, [email protected] Abstract tion can generate non-deterministic results because of their Concurrent programming is infamous for its difficulty. An unpredictable scheduling. Traditionally, developers address important source of difficulty is non-determinism, stemming these problems by protecting state from concurrent access from unpredictable interleavings of concurrent activities. via synchronisation. Yet, concurrent programming remains Futures and promises are widely-used abstractions that help an art: insufficient synchronisation leads to unsound pro- designing deterministic concurrent programs, although this grams but synchronising too much does not exploit hardware property cannot be guaranteed statically in mainstream pro- capabilities effectively for parallel execution. gramming languages. Deterministic-by-construction con- Over the years researchers have proposed concurrency current programming models avoid this issue, but they typi- models that attempt to overcome these issues. For exam- cally restrict expressiveness in important ways. ple the actor model [13] encapsulates state into actors This paper introduces a concurrent programming model, which communicate via asynchronous messages–a solution Reactive Async, which decouples concurrent computations that avoids shared state and hence (low-level) race condi- using
  • Actor-Based Concurrency by Srinivas Panchapakesan

    Actor-Based Concurrency by Srinivas Panchapakesan

    Concurrency in Java and Actor- based concurrency using Scala By, Srinivas Panchapakesan Concurrency Concurrent computing is a form of computing in which programs are designed as collections of interacting computational processes that may be executed in parallel. Concurrent programs can be executed sequentially on a single processor by interleaving the execution steps of each computational process, or executed in parallel by assigning each computational process to one of a set of processors that may be close or distributed across a network. The main challenges in designing concurrent programs are ensuring the correct sequencing of the interactions or communications between different computational processes, and coordinating access to resources that are shared among processes. Advantages of Concurrency Almost every computer nowadays has several CPU's or several cores within one CPU. The ability to leverage theses multi-cores can be the key for a successful high-volume application. Increased application throughput - parallel execution of a concurrent program allows the number of tasks completed in certain time period to increase. High responsiveness for input/output-intensive applications mostly wait for input or output operations to complete. Concurrent programming allows the time that would be spent waiting to be used for another task. More appropriate program structure - some problems and problem domains are well-suited to representation as concurrent tasks or processes. Process vs Threads Process: A process runs independently and isolated of other processes. It cannot directly access shared data in other processes. The resources of the process are allocated to it via the operating system, e.g. memory and CPU time. Threads: Threads are so called lightweight processes which have their own call stack but an access shared data.