DOCSLIB.ORG

4.2.3 Advantages and Limitations of the Π Calculus

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
4.2.3 Advantages and Limitations of the Π Calculus DynamiTE: A 21st-Century Framework for Concurrent Component-Based Design Andrew John Hughes 11th of December 2009 This thesis is submitted for the degree of Doctor of Philosophy Department of Computer Science University of Sheffield Abstract The free ride for software developers is over. In the past, computer programs have increased in performance simply by running on new hardware with ever increasing clock speeds. Now, however, this line of development has reached its end and chip designers are producing new processors, not with faster clocks, but with more cores. To take advantage of the speed increases offered by these new products, applications need to be redesigned with parallel processing firmly in mind. The problem is that mainstream designs are still inherently sequential. Concur- rency tends to be an afterthought that may be useful to gain a performance boost, not an essential part of the design process. The current vogue for object-oriented designs tends to also have the side-effect of making them heavily data-oriented which doesn’t scale well; each shared element of data has to be protected from simultane- ous access, resulting in operations becoming sequential again. In addition, the usual methods for protecting data tend to be very low-level and error-prone. In this thesis, we introduce a new design method whereby applications are con- structed from small sequential tasks connected by intercommunication primitives. Our approach is based on a two-stage process; first, the individual tasks are cre- ated as independent entities and tested with appropriate inputs, then secondly, the communication infrastructure between them is developed. We provide support for the latter via the DynamiTE framework, which allows the interactions to be defined using the terms of a process calculus. Depending on the developer’s background, they can treat this as just another API, as a design pattern or as an algebraic ex- pression which can be property checked for issues such as deadlocks. Either way, the communication layer can be developed, tested and evaluated separately from the tasks once it is known how the tasks will interface with one another. To supplement DynamiTE, we define our own process calculus, Nomadic Time, using a carefully chosen novel selection of constructs. Among the features of the calculus are the ability to perform communication both locally (one-to-one) and globally (one-to-many), and the flexibility to change the location of tasks during execution. Security is paramount to the design of Nomadic Time and migratory operations can be limited in two ways; by simple enumeration of possibilities or by the optional typing of constructs to allow restriction on a task-by-task basis. While it can’t eradicate all the problems inherent in designing concurrent appli- cations, DynamiTE can make things easier by reducing the dependency on shared resources and enhancing the reusability of concurrent components. iv Acknowledgements This work was supported by a grant from the Engineering and Physical Sciences Research Council (EPSRC) for the first three years. Thanks to everyone else for keeping it bonkers! Contents 1 Introduction 1 1.1 Rationale ................................. 1 1.2 StatusQuo ................................ 2 1.2.1 Multiprogramming . 2 1.2.2 Resource Contention . 3 1.2.3 SemaphoresandMonitors . 5 1.2.4 Interprocess Communication . 11 1.3 OurProposedSolution . 14 1.3.1 A Prototypical Application . 16 1.4 ContributionstoKnowledge . 18 1.5 StructureoftheThesis . 20 2 Algebraic Process Calculi 24 2.1 Introduction................................ 24 2.2 The Calculus of Communicating Systems . 26 2.2.1 TheDiningPhilosophers . 29 2.3 Advantages and Limitations of CCS . 31 2.4 Conclusion................................. 33 3 Global Synchronisation 35 3.1 Introduction................................ 35 3.2 TemporalProcessLanguage(TPL) . 35 3.3 ExtendingTPL .............................. 37 3.4 The Calculus of Synchronous Encapsulation . 37 3.4.1 Timeouts ............................. 38 3.4.2 ClockStoppingandInsistency . 39 3.4.3 Encapsulation........................... 40 3.5 Conclusion................................. 41 v vi CONTENTS 4 Mobility 44 4.1 Introduction................................ 44 4.2 ScopeMobility .............................. 45 4.2.1 The π Calculus .......................... 45 4.2.2 Variants of the π Calculus .................... 46 4.2.3 Advantages and Limitations of the π Calculus . 52 4.3 DistributionandMigration. 53 4.3.1 The Distributed Join Calculus . 58 4.3.2 The Ambient Calculus . 59 4.3.3 Variants of the Ambient Calculus . 62 4.3.4 Advantages and Limitations of the Ambient Calculus . 65 4.3.5 PSystems............................. 65 4.4 ComparingModellingApproaches . 68 4.5 Bigraphs.................................. 71 4.6 Conclusion................................. 72 5 Nomadic Time 74 5.1 Introduction................................ 74 5.2 LocalisingtheCalculus. 76 5.3 AddingMobility.............................. 78 5.3.1 LocationMobility. 80 5.3.2 ProcessMobility ......................... 83 5.4 Bouncers.................................. 84 5.5 TheSemantics............................... 85 5.6 ASimpleExample ............................ 91 5.7 A Prototypical Application in NT . 95 5.8 Conclusion................................. 98 6 The DynamiTE Framework 100 6.1 Introduction................................100 6.2 WhyJava?.................................101 6.2.1 Concurrency Provision . 103 6.2.2 Popularity.............................108 6.3 MappingTheorytoPracticality . 109 6.4 TheContextoftheCalculus . .114 6.4.1 ThePluginAbstraction . .116 6.5 TheEvolverFramework . .118 6.6 A Prototypical Application in DynamiTE . 123 6.7 RelatedWork ...............................131 6.7.1 Obliq................................131 6.7.2 NomadicPict ...........................134 CONTENTS vii 6.7.3 The Safe Ambients Abstract Machine . 135 6.7.4 JavaSeal ..............................136 6.8 Conclusion.................................138 7 Typed Nomadic Time 140 7.1 Introduction................................140 7.2 ExistingTypedCalculi . .140 7.2.1 Type Systems for the π Calculus ................141 7.2.2 Type Systems for the Ambient Calculus . 143 7.3 Mobility Types for Nomadic Time . 145 7.4 DynamiTEandtheTypeSystem . .149 7.5 TypedMusicalChairs . .153 7.6 Conclusion.................................154 8 Contributions and Future Work 156 8.1 OurContributions ............................156 8.2 FutureWork................................160 8.2.1 NomadicTime ..........................160 8.2.2 DynamiTE ............................162 8.2.3 TheTypeSystem.........................163 8.2.4 OtherApplications . .164 Bibliography 165 A Progress 174 B Preservation 178 List of Figures 1.1 The Traditional Software Development Process . 16 1.2 DynamiTE Variant of the Software Development Process . 16 1.3 Structure of the Prototypical Application . 18 2.1 Graph of a.0 a.0............................. 28 | 2.2 Graph of a.0+ a.0 ............................ 28 4.1 Spatial diagram of m[in n.out n.P ] n[]................. 60 4.2 Spatial diagram of n[m[out n.P ]] ....................| 60 4.3 Spatial diagram of m[P ] n[]....................... 60 4.4 ExamplePSystem ............................| 67 5.1 Derivation of Nomadic Time . 75 5.2 Clock Hiding in n[E m[F k[G]{σ}]{ρ}]{γ} ............... 78 5.3 TheMusicalChairsEnvironment| | . 92 7.1 Derivation of Typed Nomadic Time . 145 viii List of Tables 2.1 CCSSemantics .............................. 29 3.1 CaSESemantics.............................. 42 3.2 Derivation of CaSE from CCS . 43 4.1 LCCSDynamicSOSRules. 54 5.1 Feature Summary from the Literature Survey . 75 5.2 CoreSemantics .............................. 87 5.3 MobilitySemantics ............................ 88 5.4 StructuralCongruenceLaws . 88 5.5 Derivation of Nomadic Time from CaSE . 89 5.6 Summary of Processes and Derived Syntax for Musical Chairs . 93 6.1 Translation Schema from NT to DynamiTE Process Subclasses . 110 6.2 Translation Schema from NT to DynamiTE Classes . 110 7.1 Typing Rules from (Sangiorgi, 2002) . 143 7.2 Types ...................................147 7.3 TimeoutTypes ..............................147 7.4 TheBouncerType ............................147 7.5 MobilityTypes ..............................148 7.6 StructuralCongruenceLawswithTypes . 149 ix Chapter 1 Introduction 1.1 Rationale Recent changes in the direction of computer hardware development have created an impasse in the domain of software engineering. Over the past few years, new microprocessors have not seen the same increase in clock speed that has prevailed over previous decades. Instead, the use of multiple ‘cores’ has become common, due largely to physical limitations which prevent the individual elements of a single processor core becoming any smaller. As a result, the performance benefits of these new processors arise not from being able to execute a single task faster than before, but from the parallel execution of many such tasks. However, this leads to a problem. The existing dominant methods for designing software systems are inherently sequential. Current imperative and object-oriented programming languages are still founded on the principles of early computational models, such as the Turing machine (Turing, 1936). These take an idealised view of events where they always occur sequentially and in isolation. Programs are thus still effectively written as a sequence of reads and writes to a form of memory. The problem
Load more

Recommended publications
  • Introduction to Multi-Threading and Vectorization Matti Kortelainen Larsoft Workshop 2019 25 June 2019 Outline
    Introduction to multi-threading and vectorization Matti Kortelainen LArSoft Workshop 2019 25 June 2019 Outline Broad introductory overview: • Why multithread? • What is a thread? • Some threading models – std::thread – OpenMP (fork-join) – Intel Threading Building Blocks (TBB) (tasks) • Race condition, critical region, mutual exclusion, deadlock • Vectorization (SIMD) 2 6/25/19 Matti Kortelainen | Introduction to multi-threading and vectorization Motivations for multithreading Image courtesy of K. Rupp 3 6/25/19 Matti Kortelainen | Introduction to multi-threading and vectorization Motivations for multithreading • One process on a node: speedups from parallelizing parts of the programs – Any problem can get speedup if the threads can cooperate on • same core (sharing L1 cache) • L2 cache (may be shared among small number of cores) • Fully loaded node: save memory and other resources – Threads can share objects -> N threads can use significantly less memory than N processes • If smallest chunk of data is so big that only one fits in memory at a time, is there any other option? 4 6/25/19 Matti Kortelainen | Introduction to multi-threading and vectorization What is a (software) thread? (in POSIX/Linux) • “Smallest sequence of programmed instructions that can be managed independently by a scheduler” [Wikipedia] • A thread has its own – Program counter – Registers – Stack – Thread-local memory (better to avoid in general) • Threads of a process share everything else, e.g. – Program code, constants – Heap memory – Network connections – File handles
    [Show full text]
  • CSC 553 Operating Systems Multiple Processes
    CSC 553 Operating Systems Lecture 4 - Concurrency: Mutual Exclusion and Synchronization Multiple Processes • Operating System design is concerned with the management of processes and threads: • Multiprogramming • Multiprocessing • Distributed Processing Concurrency Arises in Three Different Contexts: • Multiple Applications – invented to allow processing time to be shared among active applications • Structured Applications – extension of modular design and structured programming • Operating System Structure – OS themselves implemented as a set of processes or threads Key Terms Related to Concurrency Principles of Concurrency • Interleaving and overlapping • can be viewed as examples of concurrent processing • both present the same problems • Uniprocessor – the relative speed of execution of processes cannot be predicted • depends on activities of other processes • the way the OS handles interrupts • scheduling policies of the OS Difficulties of Concurrency • Sharing of global resources • Difficult for the OS to manage the allocation of resources optimally • Difficult to locate programming errors as results are not deterministic and reproducible Race Condition • Occurs when multiple processes or threads read and write data items • The final result depends on the order of execution – the “loser” of the race is the process that updates last and will determine the final value of the variable Operating System Concerns • Design and management issues raised by the existence of concurrency: • The OS must: – be able to keep track of various processes
    [Show full text]
  • Towards Gradually Typed Capabilities in the Pi-Calculus
    Towards Gradually Typed Capabilities in the Pi-Calculus Matteo Cimini University of Massachusetts Lowell Lowell, MA, USA matteo [email protected] Gradual typing is an approach to integrating static and dynamic typing within the same language, and puts the programmer in control of which regions of code are type checked at compile-time and which are type checked at run-time. In this paper, we focus on the π-calculus equipped with types for the modeling of input-output capabilities of channels. We present our preliminary work towards a gradually typed version of this calculus. We present a type system, a cast insertion procedure that automatically inserts run-time checks, and an operational semantics of a π-calculus that handles casts on channels. Although we do not claim any theoretical results on our formulations, we demonstrate our calculus with an example and discuss our future plans. 1 Introduction This paper presents preliminary work on integrating dynamically typed features into a typed π-calculus. Pierce and Sangiorgi have defined a typed π-calculus in which channels can be assigned types that express input and output capabilities [16]. Channels can be declared to be input-only, output-only, or that can be used for both input and output operations. As a consequence, this type system can detect unintended or malicious channel misuses at compile-time. The static typing nature of the type system prevents the modeling of scenarios in which the input- output discipline of a channel is discovered at run-time. In these scenarios, such a discipline must be enforced with run-time type checks in the style of dynamic typing.
    [Show full text]
  • Mobile Processes: a Commented Bibliography
    Mobile Processes: a Commented Bibliography Silvano Dal Zilio Microsoft Research Abstract. We propose a short bibliographic survey of calculi for mobile processes. Contrasting with other similar exercises, we consider two re- lated, but distinct, notions of mobile processes, namely labile processes, which can exhibit dynamic changes in their interaction structure, as mod- elled in the π-calculus of Milner, Parrow and Walker for example, and motile processes, which can exhibit motion, as modelled in the ambient calculus of Cardelli and Gordon. A common characteristic of the alge- braic frameworks presented in this paper is the use of names as first class values and the support for the dynamic generation of new, fresh names. 1 Introduction Process algebras have proved to be valuable mathematical tools to reason about the behaviour of concurrent and communicating systems. For more than ten years now, research has been conducted on semantics of higher-order processes that allow communication channels or even processes to be carried across by communications. Process calculi featuring the ability to dynamically create and exchange channel names are often referred to as mobile, a term popularised by the seminal introduction to the π-calculus [1], a prominent example of calculus with mobile processes. 1. Robin Milner, Joachim Parrow, David Walker: A Calculus of Mobile Pro- cesses, (parts I and II). Information and Computation 100(1) (1992) 1–77 2. Robin Milner: Communicating and Mobile Systems: the Pi-Calculus. Cam- bridge University Press (2000) Unfortunately, the term mobility is overloaded with meaning and the notion of mobility supported by the π-calculus encompasses only part of all the abstrac- tions meaningful to mobility in a distributed system.
    [Show full text]
  • Enhanced Debugging for Data Races in Parallel
    ENHANCED DEBUGGING FOR DATA RACES IN PARALLEL PROGRAMS USING OPENMP A Thesis Presented to the Faculty of the Department of Computer Science University of Houston In Partial Fulfillment of the Requirements for the Degree Master of Science By Marcus W. Hervey December 2016 ENHANCED DEBUGGING FOR DATA RACES IN PARALLEL PROGRAMS USING OPENMP Marcus W. Hervey APPROVED: Dr. Edgar Gabriel, Chairman Dept. of Computer Science Dr. Shishir Shah Dept. of Computer Science Dr. Barbara Chapman Dept. of Computer Science, Stony Brook University Dean, College of Natural Sciences and Mathematics ii iii Acknowledgements A special thank you to Dr. Barbara Chapman, Ph.D., Dr. Edgar Gabriel, Ph.D., Dr. Shishir Shah, Ph.D., Dr. Lei Huang, Ph.D., Dr. Chunhua Liao, Ph.D., Dr. Laksano Adhianto, Ph.D., and Dr. Oscar Hernandez, Ph.D. for their guidance and support throughout this endeavor. I would also like to thank Van Bui, Deepak Eachempati, James LaGrone, and Cody Addison for their friendship and teamwork, without which this endeavor would have never been accomplished. I dedicate this thesis to my parents (Billy and Olivia Hervey) who have always chal- lenged me to be my best, and to my wife and kids for their love and sacrifice throughout this process. ”Our greatest weakness lies in giving up. The most certain way to succeed is always to try just one more time.” – Thomas Alva Edison iv ENHANCED DEBUGGING FOR DATA RACES IN PARALLEL PROGRAMS USING OPENMP An Abstract of a Thesis Presented to the Faculty of the Department of Computer Science University of Houston In Partial Fulfillment of the Requirements for the Degree Master of Science By Marcus W.
    [Show full text]
  • Reconciling Real and Stochastic Time: the Need for Probabilistic Refinement
    DOI 10.1007/s00165-012-0230-y The Author(s) © 2012. This article is published with open access at Springerlink.com Formal Aspects Formal Aspects of Computing (2012) 24: 497–518 of Computing Reconciling real and stochastic time: the need for probabilistic refinement J. Markovski1,P.R.D’Argenio2,J.C.M.Baeten1,3 and E. P. de Vink1,3 1 Eindhoven University of Technology, Eindhoven, The Netherlands. E-mail: [email protected] 2 FaMAF, Universidad Nacional de Cordoba,´ Cordoba,´ Argentina 3 Centrum Wiskunde & Informatica, Amsterdam, The Netherlands Abstract. We conservatively extend an ACP-style discrete-time process theory with discrete stochastic delays. The semantics of the timed delays relies on time additivity and time determinism, which are properties that enable us to merge subsequent timed delays and to impose their synchronous expiration. Stochastic delays, however, interact with respect to a so-called race condition that determines the set of delays that expire first, which is guided by an (implicit) probabilistic choice. The race condition precludes the property of time additivity as the merger of stochastic delays alters this probabilistic behavior. To this end, we resolve the race condition using conditionally-distributed unit delays. We give a sound and ground-complete axiomatization of the process the- ory comprising the standard set of ACP-style operators. In this generalized setting, the alternative composition is no longer associative, so we have to resort to special normal forms that explicitly resolve the underlying race condition. Our treatment succeeds in the initial challenge to conservatively extend standard time with stochastic time. However, the ‘dissection’ of the stochastic delays to conditionally-distributed unit delays comes at a price, as we can no longer relate the resolved race condition to the original stochastic delays.
    [Show full text]
  • Lecture 18 18.1 Distributed and Concurrent Systems 18.2 Race
    CMPSCI 691ST Systems Fall 2011 Lecture 18 Lecturer: Emery Berger Scribe: Sean Barker 18.1 Distributed and Concurrent Systems In this lecture we discussed two broad issues in concurrent systems: clocks and race detection. The first paper we read introduced the Lamport clock, which is a scalar providing a logical clock value for each process. Every time a process sends a message, it increments its clock value, and every time a process receives a message, it sets its clock value to the max of the current value and the message value. Clock values are used to provide a `happens-before' relationship, which provides a consistent partial ordering of events across processes. Lamport clocks were later extended to vector clocks, in which each of n processes maintains an array (or vector) of n clock values (one for each process) rather than just a single value as in Lamport clocks. Vector clocks are much more precise than Lamport clocks, since they can check whether intermediate events from anyone have occurred (by looking at the max across the entire vector), and have essentially replaced Lamport clocks today. Moreover, since distributed systems are already sending many messages, the cost of maintaining vector clocks is generally not a big deal. Clock synchronization is still a hard problem, however, because physical clock values will always have some amount of drift. The FastTrack paper we read leverages vector clocks to do race detection. 18.2 Race Detection Broadly speaking, a race condition occurs when at least two threads are accessing a variable, and one of them writes the value while another is reading.
    [Show full text]
  • Breadth First Search Vectorization on the Intel Xeon Phi
    Breadth First Search Vectorization on the Intel Xeon Phi Mireya Paredes Graham Riley Mikel Luján University of Manchester University of Manchester University of Manchester Oxford Road, M13 9PL Oxford Road, M13 9PL Oxford Road, M13 9PL Manchester, UK Manchester, UK Manchester, UK [email protected] [email protected] [email protected] ABSTRACT Today, scientific experiments in many domains, and large Breadth First Search (BFS) is a building block for graph organizations can generate huge amounts of data, e.g. social algorithms and has recently been used for large scale anal- networks, health-care records and bio-informatics applica- ysis of information in a variety of applications including so- tions [8]. Graphs seem to be a good match for important cial networks, graph databases and web searching. Due to and large dataset analysis as they can abstract real world its importance, a number of different parallel programming networks. To process large graphs, different techniques have models and architectures have been exploited to optimize been applied, including parallel programming. The main the BFS. However, due to the irregular memory access pat- challenge in the parallelization of graph processing is that terns and the unstructured nature of the large graphs, its large graphs are often unstructured and highly irregular and efficient parallelization is a challenge. The Xeon Phi is a this limits their scalability and performance when executing massively parallel architecture available as an off-the-shelf on off-the-shelf systems [18]. accelerator, which includes a powerful 512 bit vector unit The Breadth First Search (BFS) is a building block of with optimized scatter and gather functions.
    [Show full text]
  • Rapid Prototyping of High-Performance Concurrent Java Applications
    Rapid Prototyping of High-Performance Concurrent Java Applications K.J.R. Powell Master of Science School of Computer Science School of Informatics University of Edinburgh 2002 (Graduation date:December 2002) Abstract The design and implementation of concurrent applications is more challenging than that of sequential applications. The aim of this project is to address this challenge by producing an application which can generate skeleton Java systems from a high-level PEPA modelling language description. By automating the process of translating the design into a Java skeleton system, the result will maintain the performance and be- havioural characteristics of the model, providing a sound framework for completing the concurrent application. This method accelerates the process of initial implementation whilst ensuring the system characterisics remain true to the high-level model. i Acknowledgements Many thanks to my supervisor Stephen Gilmore for his excellent guidance and ideas. I’d also like to express my gratitude to L.L. for his assistance above and beyond the call of duty in the field of editing. ii Declaration I declare that this thesis was composed by myself, that the work contained herein is my own except where explicitly stated otherwise in the text, and that this work has not been submitted for any other degree or professional qualification except as specified. (K.J.R. Powell) iii Table of Contents 1 Introduction 1 1.1 Principal Goal . 1 1.2 PEPA and Java . 2 1.3 Project Objective . 2 2 Performance Evaluation Process Algebra 4 2.1 Overview of PEPA and its role in design . 4 2.2 The Syntax of PEPA .
    [Show full text]
  • Towards Systematic Black-Box Testing for Exploitable Race Conditions in Web Apps
    1 Faculty of Electrical Engineering, Mathematics & Computer Science Towards Systematic Black-Box Testing for Exploitable Race Conditions in Web Apps Rob J. van Emous [email protected] Master Thesis June 2019 Supervisors: prof. dr. M. Huisman dr. ing. E. Tews (Computest) M.Sc. D. Keuper Formal Methods and Tools Group Faculty of Electrical Engineering, Mathematics and Computer Science University of Twente P.O. Box 217 7500 AE Enschede The Netherlands ABSTRACT As web applications get more complicated and more integrated into our daily lives, securing them against known cyber attacks is of great importance. Performing se- curity tests is the primary way to discover the current risks and act accordingly. In order to perform these test in a systematic way, testers create and use numer- ous vulnerability lists and testing guidelines. Often, dedicated security institutions like Escal Institute of Advanced Technologies (SANS), MITRE, Certified Secure, and the Open Web Application Security Project (OWASP) create these guidelines. These lists are not meant to be exhaustive, but as the introduction in the Common Weakness Enumeration (CWE) of MITRE and SANS by Martin et al. (2011) puts it: they "(..) evaluated each weakness based on prevalence, importance, and the likelihood of exploit". This seems like a reasonable way of thinking, but as we have shown in this research, it can also lead to oversight of essential, but stealthy security issues. In this research, we will focus on one such stealthy issue in web apps called a race condition. Race conditions are known for a very long time as research by Abbott et al.
    [Show full text]
  • A Survey of Reasoning Methods for Concurrent Systems
    A Survey of Reasoning Methods for Concurrent Systems Chun-Kun Wang Hao Xu Department of Computer Science Data Intensive Cyber Environment Center Univ. of North Carolina at Chapel Hill Univ. of North Carolina at Chapel Hill Chapel Hill, NC 27599, USA Chapel Hill, NC 27599, USA Email: [email protected] Email: [email protected] Abstract—The theory of parallel and distributed systems in tial studies of formal methods for concurrency reasoning. In computer science has been developing for decades. Multiple this paper, we do not compare reasoning methods down to the methods have emerged for the purpose of providing flexibility, last detail (i.e., syntax, inference rules and proof systems). We expressiveness and theories for concurrent processes. This paper provides a comparative introduction to the history of concurrent do, however, discuss concurrency reasoning approaches from systems reasoning and a decision tree to guide the choice of a a high-level and provide a comparative introduction to them. reasoning method accordingly. Our account on these matters is The authors would like to stress that our account on the incomplete. developmental history of concurrent systems reasoning is Index Terms—Concurrent systems, Formal methods, Program incomplete. The guides to select a method accordingly are logic, Process calculi. provided in this paper. Others may well have very different views. I. INTRODUCTION Concurrency theory has been developing for decades, yet II. HISTORY remains an unsolved problem today. Modern software heavily The history of reasoning concurrency dates back to the late relies upon the services provided by distributed systems, twentieth century. The foundations of early concurrency theory ranging from smartphone applications to social media.
    [Show full text]
  • Concurrent Programming CLASS NOTES
    COMP 409 Concurrent Programming CLASS NOTES Based on professor Clark Verbrugge's notes Format and figures by Gabriel Lemonde-Labrecque Contents 1 Lecture: January 4th, 2008 7 1.1 Final Exam . .7 1.2 Syllabus . .7 2 Lecture: January 7th, 2008 8 2.1 What is a thread (vs a process)? . .8 2.1.1 Properties of a process . .8 2.1.2 Properties of a thread . .8 2.2 Lifecycle of a process . .9 2.3 Achieving good performances . .9 2.3.1 What is speedup? . .9 2.3.2 What are threads good for then? . 10 2.4 Concurrent Hardware . 10 2.4.1 Basic Uniprocessor . 10 2.4.2 Multiprocessors . 10 3 Lecture: January 9th, 2008 11 3.1 Last Time . 11 3.2 Basic Hardware (continued) . 11 3.2.1 Cache Coherence Issue . 11 3.2.2 On-Chip Multiprocessing (multiprocessors) . 11 3.3 Granularity . 12 3.3.1 Coarse-grained multi-threading (CMT) . 12 3.3.2 Fine-grained multithreading (FMT) . 12 3.4 Simultaneous Multithreading (SMT) . 12 4 Lecture: January 11th, 2008 14 4.1 Last Time . 14 4.2 \replay architecture" . 14 4.3 Atomicity . 15 5 Lecture: January 14th, 2008 16 6 Lecture: January 16th, 2008 16 6.1 Last Time . 16 6.2 At-Most-Once (AMO) . 16 6.3 Race Conditions . 18 7 Lecture: January 18th, 2008 19 7.1 Last Time . 19 7.2 Mutual Exclusion . 19 8 Lecture: January 21st, 2008 21 8.1 Last Time . 21 8.2 Kessel's Algorithm . 22 8.3 Brief Interruption to Introduce Java and PThreads .
    [Show full text]