DOCSLIB.ORG

Checking Concurrent Data Structures Under the C/C++11 Memory Model

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Checking Concurrent Data Structures Under the C/C++11 Memory Model ����� �� � � ������ � � �� � � � �� � � � � � � � � � � � Checking Concurrent Data Structures Under the C/C++11 Memory Model ifact rt * * Comple A t te n * A te s W i E * s e n l C l o P D C o P * * Peizhao Ou and Brian Demsky c u o e m s E P u e e n P R t v e o d t * y * s E a a l d u e a University of California, Irvine, USA t fpeizhaoo,[email protected] Abstract 1.1 Concurrent Data Structure Specifications Concurrent data structures often provide better performance Researchers have developed several techniques for specify- on multi-core processors but are significantly more difficult ing correctness properties of concurrent data structures writ- to design and test than their sequential counterparts. The ten for the sequential consistency memory model. While C/C++11 standard introduced a weak memory model with these techniques cannot handle the behaviors exhibited by support for low-level atomic operations such as compare data structure implementations under relaxed memory mod- and swap (CAS). While low-level atomic operations can els, they provide insight into intuitive approaches for speci- significantly improve the performance of concurrent data fying concurrent data structure behavior. structures, they introduce non-intuitive behaviors that can A common approach for specifying the correctness of increase the difficulty of developing code. concurrent data structures is in terms of sequential execu- In this paper, we develop a correctness model for con- tions of either the concurrent data structure or a simplified current data structures that make use of atomic operations. sequential version. The problem then becomes how do we Based on this correctness model, we present CDSSPEC, a map a concurrent execution to a sequential execution? A specification checker for concurrent data structures under the common criterion is linearizability — linearizability states C/C++11 memory model. We have evaluated CDSSPEC on that a concurrent operation can be viewed as taking effect at 10 concurrent data structures, among which CDSSPEC de- some time between its invocation and its response [32]. tected 3 known bugs and 93% of the injected bugs. An equivalent sequential data structure is a sequential version of a concurrent data structure that can be used to Categories and Subject Descriptors D.1.3 [Programming express correctness properties by relating executions of the Techniques]: Concurrent Programing; D.2.4 [Software En- concurrent data structure to executions of the equivalent se- gineering]: Software/Program Verification quential data structure. The equivalent sequential data struc- ture is often simpler, and in many cases, one can simply use Keywords Relaxed Memory Models; Concurrent Data existing well-tested implementations from libraries. Structure Specifications A history is a total order of the method invocations and 1. Introduction responses in an execution. A sequential history is one where Concurrent data structures can improve scalability by sup- all invocations are immediately followed by the correspond- porting multiple simultaneous operations, reducing cache ing responses. A concurrent object is linearizable if for all coherence traffic, and reducing the time taken by individual executions: (1) the invocations and responses can be re- data structure operations. Researchers have developed many ordered to yield a sequential history under the constraint that concurrent data structures with these goals [24, 35, 38]. Con- an invocation cannot be reordered before the preceding re- current data structures often use sophisticated techniques sponses and (2) the concurrent execution yields the same be- including low-level atomic instructions (e.g., compare and havior as this sequential history. swap), careful reasoning about the order of memory opera- A weaker variation of linearization is sequential consis- tions, and fine-grained locking. Developing correct concur- tency1. Sequential consistency only requires that there exists rent data structures requires subtle reasoning about the data a sequential history that is consistent with the program order structure and the memory model, and there are numerous ex- (intra-thread order). This order does not need to be consis- amples of incorrect concurrent data structures [40, 41]. tent with the order that operations were actually issued in. Unfortunately, efficient implementations of many com- mon data structures, e.g., RCU [24], MS Queue [38], etc., for the C/C++ memory model are neither linearizable [29] Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice nor sequentially consistent! and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. 1 PPoPP ’17, February 04 - 08, 2017, Austin, TX, USA Note that the term sequential consistency in the literature is applied to both Copyright © 2017 held by owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-4493-7/17/02. $15.00 the consistency model that data structures expose to clients as well as the DOI: http://dx.doi.org/10.1145/3018743.3018749 guarantees that the memory system provides for loads and stores. 1.2 New Challenges from the C/C++ Memory Model queue and dequeue operations. Figure 1 shows a problematic The C/C++ memory model [1, 2] brings the following execution of such a queue: (1) thread A initializes the fields two challenges that prevent the application of previous ap- of a new object X; (2) thread A enqueues the reference to X; proaches for specifying the correctness of concurrent data (3) thread B dequeues the reference to X; (4) thread B reads structures: the fields of X through the dequeued reference. In (4), thread Relaxed Executions Break Existing Data Structure Con- B could fail to see the initializing writes from (1). This sur- sistency Models: C/C++ data structures often expose prising behavior could occur if the compiler or CPU reorders clients to weaker (non-SC) behaviors to gain performance. the initializing writes to be executed after the enqueue oper- A common guarantee is to provide happens-before syn- ation, i.e., reordering (1) after (2). chronization between operations that perform updates and Thread A Thread B the operations that read those updates. These data struc- X->field1=1; // (1) Obj *r1=q->deq(); // (3) tures often do not guarantee that different threads ob- ... if (r1!=NULL) serve updates in the same order. For example, even when q->enq(X); // (2) int r2=r1->field1; // (4) one uses the relatively strong release and acquire Figure 1. The problematic execution of a concurrent queue (i.e., std::memory_order_release and std::memory_ in which the load in (4) does not see the initialization in (1) order_acquire) memory orderings in C++, it is possible (i.e., r2!=1) when the dequeue operation in (3) dequeues for two different threads to observe two stores happening from the enqueue operation in (2) in different orders. Thus, many data structures legitimately admit executions for which there are no sequential histories 1.3 Specification Language and Tool Support that preserve program order. This paper presents CDSSPEC, a specification checking tool Like many other relaxed memory models, the C/C++ that is designed to be used in conjunction with model check- memory model does not define a total order over all mem- ing tools. We have implemented it as a plugin for the CD- ory operations. Instead of a total order, the C/C++ memory SCHECKER model checker. After implementing a concur- model is formulated as a graph of memory operations with rent data structure, developers annotate their code with a edges representing several partial orders. This complicates CDSSPEC specification. To test their implementation, de- the application of traditional approaches to correctness, e.g., velopers compile the data structure with the CDSSPEC spec- linearization cannot be applied. Specifically, approaches that ification compiler to extract the specification and generate relate the behaviors of concurrent data structures to analo- code that is instrumented with specification checks. Then, gous sequential data structures break down due to the ab- developers compile the instrumented program with a stan- sence of a total ordering of the memory operations. While dard C/C++ compiler. Finally, developers run the binary un- many dynamic tools [40, 50] for exploring code behavior der the CDSSPEC checker. CDSSPEC then exhaustively ex- under relaxed models do as a practical matter print out an plores the behaviors of the unit test and generates diagnostic execution in some order, this order insufficient as relaxed reports for executions that violate the specification. memory models generally make it possible for a data struc- Researchers have developed tools for exploring the be- ture operation (1) to see the effects of operations that appear havior of code under the C/C++ memory model including later in any such order (e.g., a load can read from a store that CDSCHECKER [40], CPPMEM [13], and Relacy [50], and appears later in the order) and (2) to see the effects of older, also under a revised C/C++ memory model [11]. While these stale updates. tools can be used to explore executions, they can be chal- Constraining Reorderings (Specifying Synchronization lenging to use for testing as they don’t provide support be- Properties): 2 Synchronization in C/C++ orders memory yond assertions for specifying data structure behavior. operations to different locations. Concurrent data structures often establish synchronization to avoid exposing their users 1.4 Contributions to highly non-intuitive behaviors that may break client code.
Load more

Recommended publications
  • Memory Consistency
    Lecture 9: Memory Consistency Parallel Computing Stanford CS149, Winter 2019 Midterm ▪ Feb 12 ▪ Open notes ▪ Practice midterm Stanford CS149, Winter 2019 Shared Memory Behavior ▪ Intuition says loads should return latest value written - What is latest? - Coherence: only one memory location - Consistency: apparent ordering for all locations - Order in which memory operations performed by one thread become visible to other threads ▪ Affects - Programmability: how programmers reason about program behavior - Allowed behavior of multithreaded programs executing with shared memory - Performance: limits HW/SW optimizations that can be used - Reordering memory operations to hide latency Stanford CS149, Winter 2019 Today: what you should know ▪ Understand the motivation for relaxed consistency models ▪ Understand the implications of relaxing W→R ordering Stanford CS149, Winter 2019 Today: who should care ▪ Anyone who: - Wants to implement a synchronization library - Will ever work a job in kernel (or driver) development - Seeks to implement lock-free data structures * - Does any of the above on ARM processors ** * Topic of a later lecture ** For reasons to be described later Stanford CS149, Winter 2019 Memory coherence vs. memory consistency ▪ Memory coherence defines requirements for the observed Observed chronology of operations on address X behavior of reads and writes to the same memory location - All processors must agree on the order of reads/writes to X P0 write: 5 - In other words: it is possible to put all operations involving X on a timeline such P1 read (5) that the observations of all processors are consistent with that timeline P2 write: 10 ▪ Memory consistency defines the behavior of reads and writes to different locations (as observed by other processors) P2 write: 11 - Coherence only guarantees that writes to address X will eventually propagate to other processors P1 read (11) - Consistency deals with when writes to X propagate to other processors, relative to reads and writes to other addresses Stanford CS149, Winter 2019 Coherence vs.
    [Show full text]
  • Memory Consistency: in a Distributed Outline for Lecture 20 Memory System, References to Memory in Remote Processors Do Not Take Place I
    Memory consistency: In a distributed Outline for Lecture 20 memory system, references to memory in remote processors do not take place I. Memory consistency immediately. II. Consistency models not requiring synch. This raises a potential problem. Suppose operations that— Strict consistency Sequential consistency • The value of a particular memory PRAM & processor consist. word in processor 2’s local memory III. Consistency models is 0. not requiring synch. operations. • Then processor 1 writes the value 1 to that word of memory. Note that Weak consistency this is a remote write. Release consistency • Processor 2 then reads the word. But, being local, the read occurs quickly, and the value 0 is returned. What’s wrong with this? This situation can be diagrammed like this (the horizontal axis represents time): P1: W (x )1 P2: R (x )0 Depending upon how the program is written, it may or may not be able to tolerate a situation like this. But, in any case, the programmer must understand what can happen when memory is accessed in a DSM system. Consistency models: A consistency model is essentially a contract between the software and the memory. It says that iff they software agrees to obey certain rules, the memory promises to store and retrieve the expected values. © 1997 Edward F. Gehringer CSC/ECE 501 Lecture Notes Page 220 Strict consistency: The most obvious consistency model is strict consistency. Strict consistency: Any read to a memory location x returns the value stored by the most recent write operation to x. This definition implicitly assumes the existence of a global clock, so that the determination of “most recent” is unambiguous.
    [Show full text]
  • Multithreading (Concurrency) in Java “Some People, When Confronted
    Multithreading (Concurrency) in Java “Some people, when confronted with a problem, think, "I know, I’ll use threads," and then two they hav erpoblesms.” — Ned Batchelder Multi-tasking In the beginning, computers ran in batch mode: a single program with total access to all resources. Later, a multi-tasking operating system enabled multiple (independent) jobs to run (more or less) simultaneously, even though there was only a single CPU. The jobs take turns running some of their code at one time. This type of interleaving of jobs is called concurrency. Multitasking is performing two or more tasks (or jobs) at roughly the same time. Nearly all operating systems are capable of multitasking by using one of two multitasking techniques: process-based multitasking and thread-based multitasking. Each running job was (and sometimes still is) called a process, which has state (a collection of data and handles to system resources such as files and devices) and a single sequence of instructions. It turns out that many tasks are easier to write, debug, and manage if organized as multiple copies of a process (e.g., a web server). Processes are sometimes called tasks, threads, or jobs. (Although there are some distinctions between these concepts, we will ignore them for now.) Time slice, (context) switching, and scheduling are operating system (“OS”) terms related to multi-tasking. The amount of time a task is allowed to use the CPU exclusively is called a time slice, typically 10ms (a hundredth of a second) but can vary depending on your OS and other factors from 1ms to more than 120ms.
    [Show full text]
  • Towards Shared Memory Consistency Models for Gpus
    TOWARDS SHARED MEMORY CONSISTENCY MODELS FOR GPUS by Tyler Sorensen A thesis submitted to the faculty of The University of Utah in partial fulfillment of the requirements for the degree of Bachelor of Science School of Computing The University of Utah March 2013 FINAL READING APPROVAL I have read the thesis of Tyler Sorensen in its final form and have found that (1) its format, citations, and bibliographic style are consistent and acceptable; (2) its illustrative materials including figures, tables, and charts are in place. Date Ganesh Gopalakrishnan ABSTRACT With the widespread use of GPUs, it is important to ensure that programmers have a clear understanding of their shared memory consistency model i.e. what values can be read when issued concurrently with writes. While memory consistency has been studied for CPUs, GPUs present very different memory and concurrency systems and have not been well studied. We propose a collection of litmus tests that shed light on interesting visibility and ordering properties. These include classical shared memory consistency model properties, such as coherence and write atomicity, as well as GPU specific properties e.g. memory visibility differences between intra and inter block threads. The results of the litmus tests are determined by feedback from industry experts, the limited documentation available and properties common to all modern multi-core systems. Some of the behaviors remain unresolved. Using the results of the litmus tests, we establish a formal state transition model using intuitive data structures and operations. We implement our model in the Murphi modeling language and verify the initial litmus tests.
    [Show full text]
  • On the Coexistence of Shared-Memory and Message-Passing in The
    On the Co existence of SharedMemory and MessagePassing in the Programming of Parallel Applications 1 2 J Cordsen and W SchroderPreikschat GMD FIRST Rudower Chaussee D Berlin Germany University of Potsdam Am Neuen Palais D Potsdam Germany Abstract Interop erability in nonsequential applications requires com munication to exchange information using either the sharedmemory or messagepassing paradigm In the past the communication paradigm in use was determined through the architecture of the underlying comput ing platform Sharedmemory computing systems were programmed to use sharedmemory communication whereas distributedmemory archi tectures were running applications communicating via messagepassing Current trends in the architecture of parallel machines are based on sharedmemory and distributedmemory For scalable parallel applica tions in order to maintain transparency and eciency b oth communi cation paradigms have to co exist Users should not b e obliged to know when to use which of the two paradigms On the other hand the user should b e able to exploit either of the paradigms directly in order to achieve the b est p ossible solution The pap er presents the VOTE communication supp ort system VOTE provides co existent implementations of sharedmemory and message passing communication Applications can change the communication paradigm dynamically at runtime thus are able to employ the under lying computing system in the most convenient and applicationoriented way The presented case study and detailed p erformance analysis un derpins the
    [Show full text]
  • Shared Objects & Mutual Exclusion
    Chapter 4 Shared Objects & Mutual Exclusion Shared Objects & Concepts: process interference. Mutual Exclusion mutual exclusion and locks. Models: model checking for interference modelling mutual exclusion Practice: thread interference in shared Java objects mutual exclusion in Java (synchronized objects/methods). 1 2 2015 Concurrency: shared objects & mutual exclusion ©Magee/Kramer 2nd Edition 2015 Concurrency: shared objects & mutual exclusion ©Magee/Kramer 2nd Edition A Concert Hall Booking System Concert Hall Booking System const False = 0 A central computer connected to remote terminals via communication links const True = 1 is used to automate seat reservations for a concert hall. range Bool = False..True To book a seat, a client chooses a free seat and the clerk enters the number SEAT = SEAT[False], of the chosen seat at the terminal and issues a ticket, if it is free. SEAT[reserved:Bool] = ( when (!reserved) reserve -> SEAT[True] A system is required which avoids double bookings of the same seat whilst | query[reserved] -> SEAT[reserved] allowing clients free choice of the available seats. | when (reserved) reserve -> ERROR //error of reserved twice Construct an abstract model of the system and demonstrate that your model does ). not permit double bookings. Like STOP, ERROR range Seats = 1..2 is a predefined FSP ||SEATS = (seat[Seats]:SEAT). local process (state), numbered -1 in the 3 equivalent LTS. 4 2015 Concurrency: shared objects & mutual exclusion ©Magee/Kramer 2nd Edition 2015 Concurrency: shared objects & mutual exclusion ©Magee/Kramer 2nd Edition Concert Hall Booking System Concert Hall Booking System – no interference? LOCK = (acquire -> release -> LOCK). TERMINAL = (choose[s:Seats] //lock for the booking system -> seat[s].query[reserved:Bool] -> if (!reserved) then TERMINAL = (choose[s:Seats] -> acquire (seat[s].reserve -> TERMINAL) -> seat[s].query[reserved:Bool] else -> if (!reserved) then TERMINAL (seat[s].reserve -> release-> TERMINAL) ).
    [Show full text]
  • Consistency Models • Data-Centric Consistency Models • Client-Centric Consistency Models
    Consistency and Replication • Today: – Consistency models • Data-centric consistency models • Client-centric consistency models Computer Science CS677: Distributed OS Lecture 15, page 1 Why replicate? • Data replication: common technique in distributed systems • Reliability – If one replica is unavailable or crashes, use another – Protect against corrupted data • Performance – Scale with size of the distributed system (replicated web servers) – Scale in geographically distributed systems (web proxies) • Key issue: need to maintain consistency of replicated data – If one copy is modified, others become inconsistent Computer Science CS677: Distributed OS Lecture 15, page 2 Object Replication •Approach 1: application is responsible for replication – Application needs to handle consistency issues •Approach 2: system (middleware) handles replication – Consistency issues are handled by the middleware – Simplifies application development but makes object-specific solutions harder Computer Science CS677: Distributed OS Lecture 15, page 3 Replication and Scaling • Replication and caching used for system scalability • Multiple copies: – Improves performance by reducing access latency – But higher network overheads of maintaining consistency – Example: object is replicated N times • Read frequency R, write frequency W • If R<<W, high consistency overhead and wasted messages • Consistency maintenance is itself an issue – What semantics to provide? – Tight consistency requires globally synchronized clocks! • Solution: loosen consistency requirements
    [Show full text]
  • 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.
    [Show full text]
  • Sec9on 6: Mutual Exclusion
    Sec$on 6: Mutual Exclusion Michelle Ku5el [email protected] Toward sharing resources (memory) Have been studying parallel algorithms using fork- join – Lower span via parallel tasks Algorithms all had a very simple structure to avoid race condi$ons – Each thread had memory “only it accessed” • Example: array sub-range – On fork, “loaned” some of its memory to “forkee” and did not access that memory again un$l aer join on the “forkee” slide adapted from: Sophomoric Parallelism & 2 Concurrency, Lecture 4 Toward sharing resources (memory) Strategy won’t work well when: – Memory accessed by threads is overlapping or unpredictable – Threads are doing independent tasks needing access to same resources (rather than implemen$ng the same algorithm) slide adapted from: Sophomoric Parallelism & 3 Concurrency, Lecture 4 Race Condi$ons A race condi*on is a bug in a program where the output and/or result of the process is unexpectedly and cri$cally dependent on the relave sequence or $ming of other events. The idea is that the events race each other to influence the output first. Examples Mul$ple threads: 1. Processing different bank-account operaons – What if 2 threads change the same account at the same $me? 2. Using a shared cache (e.g., hashtable) of recent files – What if 2 threads insert the same file at the same $me? 3. Creang a pipeline (think assembly line) with a queue for handing work to next thread in sequence? – What if enqueuer and dequeuer adjust a circular array queue at the same $me? Sophomoric Parallelism & 5 Concurrency, Lecture 4 Concurrent
    [Show full text]
  • Challenges for the Message Passing Interface in the Petaflops Era
    Challenges for the Message Passing Interface in the Petaflops Era William D. Gropp Mathematics and Computer Science www.mcs.anl.gov/~gropp What this Talk is About The title talks about MPI – Because MPI is the dominant parallel programming model in computational science But the issue is really – What are the needs of the parallel software ecosystem? – How does MPI fit into that ecosystem? – What are the missing parts (not just from MPI)? – How can MPI adapt or be replaced in the parallel software ecosystem? – Short version of this talk: • The problem with MPI is not with what it has but with what it is missing Lets start with some history … Argonne National Laboratory 2 Quotes from “System Software and Tools for High Performance Computing Environments” (1993) “The strongest desire expressed by these users was simply to satisfy the urgent need to get applications codes running on parallel machines as quickly as possible” In a list of enabling technologies for mathematical software, “Parallel prefix for arbitrary user-defined associative operations should be supported. Conflicts between system and library (e.g., in message types) should be automatically avoided.” – Note that MPI-1 provided both Immediate Goals for Computing Environments: – Parallel computer support environment – Standards for same – Standard for parallel I/O – Standard for message passing on distributed memory machines “The single greatest hindrance to significant penetration of MPP technology in scientific computing is the absence of common programming interfaces across various parallel computing systems” Argonne National Laboratory 3 Quotes from “Enabling Technologies for Petaflops Computing” (1995): “The software for the current generation of 100 GF machines is not adequate to be scaled to a TF…” “The Petaflops computer is achievable at reasonable cost with technology available in about 20 years [2014].” – (estimated clock speed in 2004 — 700MHz)* “Software technology for MPP’s must evolve new ways to design software that is portable across a wide variety of computer architectures.
    [Show full text]
  • Java Concurrency Framework by Sidartha Gracias
    Java Concurrency Framework Sidartha Gracias Executive Summary • This is a beginners introduction to the java concurrency framework • Some familiarity with concurrent programs is assumed – However the presentation does go through a quick background on concurrency – So readers unfamiliar with concurrent programming should still get something out of this • The structure of the presentation is as follows – A brief history into concurrent programming is provided – Issues in concurrent programming are explored – The framework structure with all its major components are covered in some detail – Examples are provided for each major section to reinforce some of the major ideas Concurrency in Java - Overview • Java like most other languages supports concurrency through thread – The JVM creates the Initial thread, which begins execution from main – The main method can then spawn additional threads Thread Basics • All modern OS support the idea of processes – independently running programs that are isolated from each other • Thread can be thought of as light weight processes – Like processes they have independent program counters, call stacks etc – Unlike Processes they share main memory, file pointers and other process state – This means thread are easier for the OS to maintain and switch between – This also means we need to synchronize threads for access to shared resources Threads Continued… • So why use threads ? – Multi CPU systems: Most modern systems host multiple CPU’s, by splitting execution between them we can greatly speed up execution – Handling Asynchronous Events: Servers handle multiple clients. Processing each client is best done through a separate thread, because the Server blocks until a new message is received – UI or event driven Processing: event handlers that respond to user input are best handled through separate threads, this makes code easier to write and understand Synchronization Primitives in Java • How does the java language handle synchronization – Concurrent execution is supported through the Thread class.
    [Show full text]
  • Java Concurrency in Practice
    Java Concurrency in practice Chapters: 1,2, 3 & 4 Bjørn Christian Sebak ([email protected]) Karianne Berg ([email protected]) INF329 – Spring 2007 Chapter 1 - Introduction Brief history of concurrency Before OS, a computer executed a single program from start to finnish But running a single program at a time is an inefficient use of computer hardware Therefore all modern OS run multiple programs (in seperate processes) Brief history of concurrency (2) Factors for running multiple processes: Resource utilization: While one program waits for I/O, why not let another program run and avoid wasting CPU cycles? Fairness: Multiple users/programs might have equal claim of the computers resources. Avoid having single large programs „hog“ the machine. Convenience: Often desirable to create smaller programs that perform a single task (and coordinate them), than to have one large program that do ALL the tasks What is a thread? A „lightweight process“ - each process can have many threads Threads allow multiple streams of program flow to coexits in a single process. While a thread share process-wide resources like memory and files with other threads, they all have their own program counter, stack and local variables Benefits of threads 1) Exploiting multiple processors 2) Simplicity of modeling 3) Simplified handling of asynchronous events 4) More responsive user interfaces Benefits of threads (2) Exploiting multiple processors The processor industry is currently focusing on increasing number of cores on a single CPU rather than increasing clock speed. Well-designed programs with multiple threads can execute simultaneously on multiple processors, increasing resource utilization.
    [Show full text]