"First Class Futures"

Total Page:16

File Type:pdf, Size:1020Kb

UNIVERSITÉ DE NICE - SOPHIA ANTIPOLIS École Doctorale STIC Sciences et Technologies de l’Information et de la Communication THÈSE pour obtenir le titre de Docteur en Sciences de l’Université de Nice - Sophia Antipolis Mention Informatique présentée et soutenu par Muhammad Uzair KHAN A Study of First Class Futures: Specification, Formalisation, and Mechanised Proofs Thèse dirigée par Ludovic HENRIO et Denis CAROMEL au sein de l’équipe OASIS, équipe commune de l’INRIA Sophia Antipolis, du CNRS et du laboratoire I3S soutenue le 25 Février 2011,devant le jury composé de: Président du Jury Yves Bertot INRIA-Sophia Antipolis Rapporteurs Jean-Bernard Stefani INRIA Grenoble-Rhône-Alpes, France Christian Perez INRIA-ENS Lyon, France Carlos Canal ETSI Informática Universidad de Málaga, Espagne Directeur de thèse Denis Caromel INRIA-CNRS-Université de Nice Sophia Antipolis Co-directeur Ludovic Henrio INRIA-CNRS-I3S–Sophia Antipolis 0.1 Acknowledgment Last thing to do :-) Contents 0.1 Acknowledgment.............................i 1 Introduction1 1.1 Motivation.................................2 1.2 Results and Contributions........................3 1.2.1 Specification and Implementation of Future Update Strategies4 1.2.2 Formalisation of Component Model and Proofs........4 1.3 Impact of Thesis.............................5 1.4 Thesis Outline..............................5 2 Related Works9 2.1 Background: Why Futures ?....................... 10 2.1.1 Some basic questions about futures............... 11 2.2 Distributed and Concurrent Programming............... 13 2.3 Distributed Concurrent Programming with Futures.......... 14 2.3.1 Futures in Multilisp World................... 14 2.3.2 Futures in ABCL/1 and ABCL/f................ 17 2.3.3 Futures in Alice ML and λ(fut) ................. 19 2.4 Distributed Concurrent Programming with Futures and Objects... 20 2.4.1 Future in Java-verse....................... 20 2.4.2 Futures in Creol......................... 22 2.4.3 Futures in ASP, ProActive and ASPfun ............. 24 2.4.4 Futures in AmbientTalk..................... 25 2.5 Component Models and Frameworks.................. 27 2.5.1 Common Object Model (COM) and DCOM.......... 28 2.5.2 Enterprise Java Beans...................... 28 2.5.3 CORBA Component Model (CCM) and GridCCM...... 29 2.5.4 Common Component Architecture (CCA)........... 30 2.5.5 Service Component Architecture (SCA) and FraSCAti.... 31 2.5.6 SOFtware Appliances Component Model (SOFA)....... 32 2.5.7 Fractal component model.................... 33 2.5.8 Grid Component Model (GCM)................. 34 2.6 Summary of Related Works and Positioning.............. 36 I Future Update Strategies: Specification and Implementation 41 3 First Class Futures: Specification of Update Strategies 43 3.1 Background: Futures in ASP-Calculus................. 45 3.2 Background: Update Strategies for Futures.............. 47 3.2.1 Classification of Future Update strategies........... 47 iv Contents 3.2.2 Eager Forward-based Strategy.................. 48 3.2.3 Eager Message-based Strategy.................. 49 3.2.4 Lazy Message-based Strategy.................. 51 3.3 Semi-Formal Specification of Update Strategies............ 52 3.3.1 General Notation......................... 52 3.3.2 Eager Forward-based Strategy.................. 55 3.3.3 Eager Message-based Strategy.................. 56 3.3.4 Lazy Message-based Strategy.................. 58 3.4 Analysis of Future Update Strategies.................. 59 3.5 Remarks on Semi-formal Specification of Strategies.......... 62 4 Implementing Future Update Strategies in ProActive 65 4.1 Background: First Class Futures in ProActive............. 66 4.1.1 First Class Futures in ProActive: Automatic Continuation.. 68 4.2 Missing Future Update Strategies.................... 70 4.2.1 Eager Message-based Strategy.................. 70 4.2.2 Lazy Message-based Strategy.................. 72 4.3 Experimental Evaluation......................... 74 4.4 Concluding Remarks on Future Update Strategies.......... 79 II Formal Reasoning on Components: Semantics and Proofs 81 5 A Framework for Reasoning on Component Composition 83 5.1 Background: Isabelle/HOL....................... 85 5.1.1 Isabelle/HOL Syntax....................... 86 5.2 An Asynchronous Component Model with Futures.......... 89 5.2.1 Component Model Overview.................. 90 5.2.2 Component Structure...................... 90 5.2.3 Communication Model...................... 92 5.2.4 Component Behaviour...................... 93 5.2.5 Why First Class Futures in GCM ?............... 94 5.3 Formalisation of a Component Model in Isabelle/HOL........ 96 5.3.1 Component Structure...................... 97 5.3.2 Efficient Specification of Component Manipulation...... 98 5.3.3 Component State......................... 103 5.3.4 Correct Component....................... 106 5.3.5 Basic Properties on Component Structure and Manipulation. 107 5.3.6 Properties on Component Correctness............. 109 5.4 Runtime Reconfiguration of Components................ 111 5.4.1 Complete Component...................... 112 5.4.2 Reconfiguration Primitives: Unbind and Replace....... 113 Contents v 6 Asynchronous Components with Futures : Semantics and Proofs 117 6.1 An Asynchronous Component Model with Futures.......... 119 6.2 Run time Semantics for GCM-like Components............ 121 6.2.1 Structure and Notations..................... 121 6.2.2 Semantics of Component Model................. 126 6.3 Formalisation in Isabelle and Properties................ 133 6.3.1 Semantics............................. 134 6.3.2 Properties and Proofs on Eager message-based Strategy... 135 7 Positioning and Concluding Remarks on Formalisation 139 8 Conclusion 143 8.1 Final remarks............................... 150 9 Future Works 153 9.1 Applied Aspects............................. 153 9.2 Theoretical Aspects............................ 157 A Summary of terms and notations 161 B Semantics of Lazy message-based Strategy 167 Bibliography 171 List of Figures 3.1 Futures propagate throughout the system............... 46 3.2 Eager forward-based: Future updates follow the flow of futures... 48 3.3 Eager message-based: All future recipients register.......... 50 3.4 Lazy message-based: Register only on wait-by-necessity....... 51 3.5 Future-update in eager forward-based strategy............. 56 3.6 Future-update in eager message-based strategy............ 57 3.7 Future update in lazy message-based strategy............. 58 4.1 Anatomy of an Active Object...................... 67 4.2 Active objects and futures in ProActive................ 68 4.3 A small example tree configuration................... 75 4.4 Comparison of strategies for a tree configuration........... 76 4.5 Pipe of varying length.......................... 77 4.6 Comparison of strategies for a pipe configuration........... 78 5.1 High level view of a GCM component [1]............... 90 5.2 Component composition......................... 91 5.3 Structure of a primitive component.................. 92 5.4 Example composite component..................... 92 5.5 Behaviour of primitive components................... 94 5.6 First Class Futures in GCM (a).................... 94 5.7 First Class Futures in GCM (b).................... 95 5.8 First Class Futures in GCM (c)..................... 95 5.9 First Class Futures in GCM (d)..................... 96 5.10 Composite Component......................... 98 6.1 Future registration............................ 120 6.2 Future update.............................. 121 6.3 Structure and behaviour of a primitive component.......... 123 6.4 Primitive Component Semantics.................... 127 6.5 Component Communications...................... 129 6.6 CompositeCall ............................ 129 6.7 Semantics of the component composition (a)............. 130 6.8 CommBrother ............................. 131 6.9 CommChild rule............................ 132 6.10 CommParent .............................. 132 6.11 Semantics of the component composition (b)............. 133 B.1 Primitive Component Semantics (Lazy message-based)........ 167 B.2 Semantics of the component composition (a)............. 168 B.3 Semantics of the components...................... 169 Chapter 1 Introduction Contents 1.1 Motivation.............................2 1.2 Results and Contributions....................3 1.2.1 Specification and Implementation of Future Update Strategies4 1.2.2 Formalisation of Component Model and Proofs........4 1.3 Impact of Thesis..........................5 1.4 Thesis Outline...........................5 2 Chapter 1. Introduction 1.1 Motivation Ever since the introduction and first serious applications of computer networks in 1970-1980s, the field of distributed computing has been growing enormously. Start- ing from their humble roots as E-mail application of ARPANET and the Usenet discussion system, distributed systems have become prevalent in modern life. Every aspect of modern life is somehow influenced by one or more applications of dis- tributed computing. At the same time, the computational capabilities of individual microprocessors have grown exponentially. Today’s processors used in standalone machines are more powerful than some of the earliest mainframes. To better harness the available processing power, and to optimise the computational efficiency, a lot of effort has been put on studying concurrency, parallelism and distribution. Distributed systems have been described in literature in a number of ways, de- pending upon factors such as distribution model, communication model,
Recommended publications
  • Ambient-Oriented Programming in Fractal
    Ambient-Oriented Programming in Fractal AleˇsPlˇsek, Philippe Merle and Lionel Seinturier Project ADAM LIFL, INRIA-Futurs, Universit´edes Sciences et Technologies de Lille (USTL), FRANCE, { plsek | merle | seinturi }@lifl.fr Abstract. Ambient-Oriented Programming (AmOP) comprises a suite of challenges that are hard to meet by current software development techniques. Although Component-Oriented Programming (COP) repre- sents promising approach, the state-of-the-art component models do not provide sufficient adaptability towards specific constraints of the Ambi- ent field. In this position paper we argue that merging AmOP and COP can be achieved by introducing the Fractal component model and its new feature : Component-Based Controlling Membranes. The proposed solution allows dynamical adaptation of component systems towards the challenges of the Ambient world. 1 Introduction Ambient-Oriented Programming (AmOP) [1] as a new trend in software devel- opment comprises a suite of challenges which are yet to be addressed fully. So far, only a few solutions facing the obstacles of ambient programming have been developed. In this paper we focus on AmbientTalk [1] since in our opinion it represents one of the most sophisticated solutions. Although AmbientTalk conceptually proposes a way to implement applica- tions for the ambient environment, this is achieved by defining a new program- ming language. Consequently, AmbientTalk potentially introduces a steep learn- ing curve for the developers. From this point of view, it is reasonable to search for an approach which uses well-known techniques and is powerful enough to face the obstacles of ambient programming. We believe that these requirements can be met by the introduction of Component-Based Software Engineering techniques.
    [Show full text]
  • Ambient-Oriented Programming in Ambienttalk
    Ambient-Oriented Programming in AmbientTalk Jessie Dedecker?, Tom Van Cutsem?, Stijn Mostinckx??, Theo D’Hondt, and Wolfgang De Meuter jededeck | tvcutsem | smostinc | tjdhondt | [email protected] Programming Technology Laboratory Vrije Universiteit Brussel, Belgium Abstract. A new field in distributed computing, called Ambient Intel- ligence, has emerged as a consequence of the increasing availability of wireless devices and the mobile networks they induce. Developing soft- ware for mobile networks is extremely hard in conventional programming languages because the network is dynamically demarcated. This leads us to postulate a suite of characteristics of future Ambient-Oriented Pro- gramming languages. A simple reflective programming language, called AmbientTalk, that meets the characteristics is presented. It is validated by implementing a collection of high level language features that are used in the implementation of an ambient messenger application . 1 Introduction Software development for mobile devices is given a new impetus with the advent of mobile networks. Mobile networks surround a mobile device equipped with wireless technology and are demarcated dynamically as users move about. Mo- bile networks turn isolated applications into cooperative ones that interact with their environment. This vision of ubiquitous computing, originally described by Weiser [38], has recently been termed Ambient Intelligence (AmI for short) by the European Council’s IST Advisory Group [12]. Mobile networks that surround a device have several properties that distin- guish them from other types of networks. The most important ones are that connections are volatile (because the communication range of wireless technol- ogy is limited) and that the network is open (because devices can appear and disappear unheraldedly).
    [Show full text]
  • CV Tom Van Cutsem (September 2019) 1 / 3 Jan
    Tom Van Cutsem Curriculum Vitae Personal Residence E-mail: [email protected] Leuven, Belgium Web: tvcutsem.github.io Linked-in: be.linkedin.com/in/tomvc Languages: Dutch (Mother Tongue), Twitter: @tvcutsem English (Fluent), French (Elementary) Education Oct. 2004 - May 2008: PhD in Computer Science, Vrije Universiteit Brussel, Greatest Distinction. • Doctoral dissertation: “Ambient references: object designation in mobile ad hoc networks”. Promotors: Prof. Dr. Wolfgang De Meuter, Prof. Dr. Theo D’Hondt. • My PhD contribution focused on mobile computing platforms (long before iOS and Android appeared). Our AmbientTalk language was featured in MIT Technology Review (http:// goo.gl/n0TGA), at droidcon.be 2011 in Brussels and covered in the Belgian techzine Datanews (http://goo.gl/B35V4x). Oct. 2000 - June 2004: Master of Science (MSc) in Computer Science, Vrije Universiteit Brussel, Greatest Distinction (GPA 18.76 / 20 or 93.8%). Valedictorian. Professional Experience Nov. 2016 - present: Department Head at Nokia Bell Labs Antwerp, Belgium • Led the transformation of a networks-focused research team into an AI research focused team, with breakthrough research in applying AI to software engineering. Built and open sourced an AI-based search engine for software libraries named Code Compass. • Thought leader on Nokia’s strategy to embrace Artificial Intelligence in research. Visibility at the level of Nokia CEO, CTO and Board of Directors. Feb. 2014 - Nov. 2016: Senior Researcher at Nokia Bell Labs Antwerp, Belgium • Architected and co-authored a distributed IoT stream processing platform ( world- widestreams.io ). Academic impact (ACM DEBS 2017 Best demo award) as well as business impact (successful transfer to business group with customer delivery).
    [Show full text]
  • Loosely-Coupled Distributed Reactive Programming in Mobile Ad Hoc Networks
    Loosely-Coupled Distributed Reactive Programming in Mobile Ad Hoc Networks Andoni Lombide Carreton, Stijn Mostinckx, Tom Van Cutsem, and Wolfgang De Meuter Software Languages Lab Vrije Universiteit Brussel, Pleinlaan 2 1050 Brussel, Belgium {alombide,smostinc,tvcutsem,wdmeuter}@vub.ac.be Abstract. Pervasive applications running on mobile ad hoc networks have to be conceived as loosely-coupled event-driven architectures be- cause of the dynamic nature of both the underlying network and the applications running on top of them. Such architectures can become te- dious to develop and understand when the number of events and event handlers increases. The reason is that the control flow of the application is driven by event handlers or callbacks which are triggered indepen- dently and are scattered throughout the application code. In this paper, we propose a number of language constructs that reconcile the elegant processing of events of a reactive programming system with the loose coupling of a publish/subscribe system that is required to cope with the dynamic nature of mobile ad hoc networks. Keywords: reactive programming, publish/subscribe, event-driven pro- gramming, mobile ad hoc networks. 1 Introduction Pervasive applications running in mobile ad hoc networks cannot be structured as monolithic programs which accept a fixed input and compute it into some output. Instead, to allow responsiveness to changes in the dynamically changing mobile ad hoc network, programming paradigms targeting pervasive applications propose the adoption of event-driven architectures [1,2,3,4]. The traditional way of conceiving an event-driven system in a setting where producers and consumers change at runtime is by adopting a publish/subscribe architecture, where event producers publish events and event consumers sub- scribe and react to events, either using a topic-based or content-based subscrip- tion [5,6].
    [Show full text]
  • An Evaluation of Interaction Paradigms for Active Objects
    An Evaluation of Interaction Paradigms for Active Objects Farzane Karami, Olaf Owe, Toktam Ramezanifarkhani Department of Informatics, University of Oslo, Norway Abstract Distributed systems are challenging to design properly and prove correctly due to their heterogeneous and distributed nature. These challenges depend on the programming paradigms used and their semantics. The actor paradigm has the advantage of offering a modular semantics, which is useful for composi- tional design and analysis. Shared variable concurrency and race conditions are avoided by means of asynchronous message passing. The object-oriented paradigm is popular due to its facilities for program structuring and reuse of code. These paradigms have been combined by means of concurrent objects where remote method calls are transmitted by message passing and where low- level synchronization primitives are avoided. Such kinds of objects may exhibit active behavior and are often called active objects. In this setting the concept of futures is central and is used by a number of languages. Futures offer a flexible way of communicating and sharing computation results. However, futures come with a cost, for instance with respect to the underlying implementation support, including garbage collection. In particular this raises a problem for IoT systems. The purpose of this paper is to reconsider and discuss the future mechanism and compare this mechanism to other alternatives, evaluating factors such as expressiveness, efficiency, as well as syntactic and semantic complexity including ease of reasoning. We limit the discussion to the setting of imperative, active objects and explore the various mechanisms and their weaknesses and advan- tages. A surprising result (at least to the authors) is that the need of futures in this setting seems to be overrated.
    [Show full text]
  • Collective Behavior – Adrian Kuhn
    Third Workshop on Dynamic Languages and Applications Alexandre Bergel1, Wolfgang De Meuter2, St´ephaneDucasse3, Oscar Nierstrasz4, Roel Wuyts5 1 Software Architecture Group, Hasso-Plattner-Institut, Germany 2 Vrije Universiteit Brussel, Belgium 3 University of Savoie, France 4 Software Composition Group, University of Bern, Switzerland 5 IMEC & Universit´eLibre de Bruxelles, Belgium Abstract. Following last two years' workshop on dynamic languages at the ECOOP conference, the Dyla 2007 workshop was a successful and popular event. As its name implies, the workshop's focus was on dynamic languages and their applications. Topics and discussions at the workshop included macro expansion mechanisms, extension of the method lookup algorithm, language interpretation, reflexivity and languages for mobile ad hoc networks. The main goal of this workshop was to bring together different dynamic language communities and favouring cross communities interaction. Dyla 2007 was organised as a full day meeting, partly devoted to presentation of submitted position papers and partly devoted to tool demonstration. All accepted papers can be downloaded from the workshop's web site. In this report, we provide an overview of the presentations and a sum- mary of discussions. 1 Workshop Description and Objective The advent of Java and C# has been a major breakthrough in the adoption of some important object-oriented language characteristics. It turned academic features like interfaces, garbage-collection and meta-programming into technolo- gies generally accepted by industry. But the massive adoption of these languages now also gives rise to a growing awareness of their limitations. On the one hand, researchers and practitioners feel themselves wrestling with the static type sys- tems, the overly complex abstract grammars, the simplistic concurrency pro- visions, the very limited reflection capabilities and the absence of higher-order language constructs such as delegation, closures and continuations.
    [Show full text]
  • The Grace Programming Language Draft Specification Version 0.5. 2025" (2015)
    Portland State University PDXScholar Computer Science Faculty Publications and Presentations Computer Science 2015 The Grace Programming Language Draft Specification ersionV 0.5. 2025 Andrew P. Black Portland State University, [email protected] Kim B. Bruce James Noble Follow this and additional works at: https://pdxscholar.library.pdx.edu/compsci_fac Part of the Programming Languages and Compilers Commons Let us know how access to this document benefits ou.y Citation Details Black, Andrew P.; Bruce, Kim B.; and Noble, James, "The Grace Programming Language Draft Specification Version 0.5. 2025" (2015). Computer Science Faculty Publications and Presentations. 140. https://pdxscholar.library.pdx.edu/compsci_fac/140 This Working Paper is brought to you for free and open access. It has been accepted for inclusion in Computer Science Faculty Publications and Presentations by an authorized administrator of PDXScholar. Please contact us if we can make this document more accessible: [email protected]. The Grace Programming Language Draft Specification Version 0.5.2025 Andrew P. Black Kim B. Bruce James Noble April 2, 2015 1 Introduction This is a specification of the Grace Programming Language. This specifica- tion is notably incomplete, and everything is subject to change. In particular, this version does not address: • James IWE MUST COMMIT TO CLASS SYNTAX!J • the library, especially collections and collection literals • static type system (although we’ve made a start) • module system James Ishould write up from DYLA paperJ • dialects • the abstract top-level method, as a marker for abstract methods, • identifier resolution rule. • metadata (Java’s @annotations, C] attributes, final, abstract etc) James Ishould add this tooJ Kim INeed to add syntax, but not necessarily details of which attributes are in language (yet)J • immutable data and pure methods.
    [Show full text]
  • The Network As a Language Construct
    The Network as a Language Construct Tony Garnock-Jones1, Sam Tobin-Hochstadt2, and Matthias Felleisen1 1Northeastern University, Boston, Massachusetts, USA 2Indiana University, Bloomington, Indiana, USA Abstract. The actor model inspires several important programming languages. In this model, communicating concurrent actors collaborate to produce a result. A pure actor language tends to turn systems into an organization-free collection of processes, however, even though most applications call for layered and tiered architectures. To address this lack of an organizational principle, programmers invent design patterns. This paper investigates integrating some of these basic patterns via a programming language construct. Specifically, it extends a calculus of communicating actors with a “network” construct so that actors can conduct scoped, tiered conversations. The paper then sketches how to articulate design ideas in the calculus, how to implement it, and how such an implementation shapes application programming. 1 Organizing Squabbling Actors Hewitt’s actor model [16] presents computation as a collaboration of concurrent and possibly parallel agents. Collaboration necessitates communication, and all communication among actors happens by message passing. The resulting sepa- ration of actors isolates resources and thus prevents conflicting use due to com- peting activities. Several programming languages and frameworks use the actor model as a design guideline, most prominently Erlang [8] and Scala [14]. Like the λ-calculus, the actor model is an elegant foundation for language design but fails to scale to real systems. Hence, a pure actor language turns programs and systems into organization-free “soups of processes.” More precisely, the model provides no organizational principle that helps programmers arrange collections of actors into a layered or tiered architecture; also out of scope is the management and monitoring of actors via actors.
    [Show full text]
  • Causeway: a Message-Oriented Distributed Debugger Terry Stanley Tyler Close Mark S
    Causeway: A message-oriented distributed debugger Terry Stanley Tyler Close Mark S. Miller Teleometry Design Hewlett Packard Labs Google Research [email protected] [email protected] [email protected] Abstract debugger, or some combination. Prior distributed An increasing number of developers face the difficult task debuggers emphasize this process-oriented view of of debugging distributed asynchronous programs. This distributed computation [31]. trend has outpaced the development of adequate debugging With the emergence of the web as an application platform, tools and currently, the best option for many is an ad hoc communicating event loops are rapidly becoming the patchwork of sequential tools and printf debugging. mainstream model for distributed computation. The web This paper presents Causeway, a postmortem distributed browser runs multiple isolated JavaScript programs. Each debugger that demonstrates a novel approach to runs as an event loop, processing user interface events as understanding the behavior of a distributed program. Our well as asynchronous messages from a server [32]. With message-oriented approach borrows an effective strategy upcoming web standards, JavaScript event loops within the from sequential debugging: To find the source of browser will be able to send asynchronous messages to unintended side-effects, start with the chain of expressed each other [4, 5] and to multiple servers [6, 7]. intentions. In the communicating event loops model, there are no We show how Causeway's integrated views – describing explicit receive operations; rather, each received message both distributed and sequential computation – help users notifies a callback, spawning a sequential call-return navigate causal pathways as they pursue suspicions. We computation which executes to completion.
    [Show full text]
  • Language Constructs for Safe Parallel Programming on Multi- Cores
    Digital Comprehensive Summaries of Uppsala Dissertations from the Faculty of Science and Technology 1319 Language Constructs for Safe Parallel Programming on Multi- Cores JOHAN ÖSTLUND ACTA UNIVERSITATIS UPSALIENSIS ISSN 1651-6214 ISBN 978-91-554-9413-1 UPPSALA urn:nbn:se:uu:diva-266795 2016 Dissertation presented at Uppsala University to be publicly examined in 2446, ITC, Lägerhyddsvägen 2, hus 2, Uppsala, Monday, 18 January 2016 at 13:00 for the degree of Doctor of Philosophy. The examination will be conducted in English. Faculty examiner: CR1 Ludovic Henrio (INRIA Sophia Antipolis). Abstract Östlund, J. 2016. Language Constructs for Safe Parallel Programming on Multi-Cores. Digital Comprehensive Summaries of Uppsala Dissertations from the Faculty of Science and Technology 1319. 105 pp. Uppsala: Acta Universitatis Upsaliensis. ISBN 978-91-554-9413-1. The last decade has seen the transition from single-core processors to multi-cores and many- cores. This move has by and large shifted the responsibility from chip manufacturers to programmers to keep up with ever-increasing expectations on performance. In the single-core era, improvements in hardware capacity could immediately be leveraged by an application: faster machine - faster program. In the age of the multi-cores, this is no longer the case. Programs must be written in specific ways to utilize available parallel hardware resources. Programming language support for concurrent and parallel programming is poor in most popular object-oriented programming languages. Shared memory, threads and locks is the most common concurrency model provided. Threads and locks are hard to understand, error-prone and inflexible; they break encapsulation - the very foundation of the object-oriented approach.
    [Show full text]
  • A Programming Model and Language for Concurrent and Distributed Object-Oriented Systems
    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.
    [Show full text]
  • An Optimised Flow for Futures: from Theory to Practice
    An Optimised Flow for Futures: From Theory to Practice Nicolas Chappea, Ludovic Henrioa, Amaury Mailléa, Matthieu Moya, and Hadrien Renauda,b a Univ Lyon, EnsL, UCBL, CNRS, Inria, LIP, F-69342, LYON Cedex 07, France b École Polytechnique/Institut Polytechnique de Paris, Palaiseau, France Abstract A future is an entity representing the result of an ongoing computation. A synchronisation with a “get” operation blocks the caller until the computation is over, to return the corresponding value. When a computation in charge of fulfilling a future delegates part of its processing to another task, mainstream languages return nested futures, and several “get” operations are needed to retrieve the computed value (we call such futures “control-flow futures”). Several approaches were proposed to tackle this issues: the “forward” construct, that allows the programmer to make delegation explicit and avoid nested futures, and “data-flow explicit futures” which natively collapse nested futures into plain futures. This paper supports the claim that data-flow explicit futures form a powerful set of language primitives, on top of which other approaches can be built. We prove the equivalence, in the context of data-flow explicit futures, between the “forward” construct and classical “return” from functions. The proof relies on a branching bisimulation between a program using “forward” and its “return” counterpart. This result allows language designers to consider “forward” as an optimisation directive rather than as a language primitive. Following the principles of the Godot system, we provide a library implementation of control-flow futures, based on data-flow explicit futures implemented in the compiler. This small library supports the claim that the implementation of classical futures based on data-flow ones is easier than the opposite.
    [Show full text]