DOCSLIB.ORG

Design Patterns for Concurrency

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Design Patterns for Concurrency Assessing Design Patterns for Concurrency Fikre Leguesse Supervisor: Dr. Adrian Francalanza Department of Computer Science & Artificial Intelligence University of Malta May 2009 Submitted in partial fulfillment of the requirements for the degree of B.Sc. I.T. (Hons.) FACULTY OF INFORMATION AND COMMUNICATION TECHNOLOGY Declaration Plagiarism is defined as “the unacknowledged use, as one’s own work, of work of another person, whether or not such work has been published” (Regulations Governing Conduct at Examinations, 1997, Regulation 1 (viii), University of Malta). I the undersigned, declare that the Final Year Project report submitted is my work, except where acknowledged and referenced. I understand that the penalties for making a false declaration may include, but are not limited to, loss of marks; cancellation of examination results; enforced suspension of studies; or expulsion from the degree programme. Work submitted without this signed declaration will not be corrected, and will be given zero marks. (N.B. If the assignment is meant to be submitted anonymously, please sign this form and submit it to the Departmental Officer separately from the assignment). _____________________________ ____________________________ Student Name Signature ________________ ________________________________________________ Course Code Title of work submitted _________________ Date Assessing Design Patterns for Concurrency Fikre Leguesse B.Sc. I.T. (Hons) May 2009 Abstract In this report we address the lack of design patterns in the message passing concurrency setting by adapting existing design patterns from the object-oriented paradigm to Erlang, a language based on the message passing concurrency setting. Over the years, the object-oriented community has been reaping the benefits associated with the adoption of design patterns, such as design reusa- bility, design flexibility, and a common vocabulary for the articulation of design ideas. The ob- ject-oriented community has been a primary adopter of design patterns, and design patterns are often considered to belong exclusively to this paradigm. In this report we argue that is not the case. We attempt to show that the benefits associated with design patterns can also be achieved in a message passing concurrency setting by implementing a number of existing concurrency related patterns using Erlang. We then integrate these patterns in the design and implementation of a peer-to-peer file sharing application that serves as a case study in the analysis of the applicability and feasibility in the adoption of design patterns to this paradigm. i Acknowledgements I would like to thank my supervisor, Dr. Adrian Francalanza who guided me throughout the project. I am truly grateful for the tireless effort and dedication with which he has given himself to all my needs in the accomplishment of this task, and for the interest he has shown in my work. I also appreciate the constant encouragement and support that he has always shown. I would also like to thank my family for their moral support throughout this challenging year. It would not have been as pleasant as it turned out to be without them by my side. ii Table of Contents Assessing Design Patterns for Concurrency ..................................................................................... i 1. Introduction .............................................................................................................................. 1 1.1 Aims and Objectives ........................................................................................................ 1 1.2 Approach and Project Methodologies ............................................................................. 2 1.3 Dissertation Overview ..................................................................................................... 3 2. Background .............................................................................................................................. 5 2.1 Design Patterns ................................................................................................................ 6 2.1.1 Brief History .............................................................................................................. 6 2.1.2 Structure..................................................................................................................... 7 2.1.3 Benefits Associated with Design Patterns ................................................................. 8 2.1.4 Design Patterns for Concurrency ............................................................................... 9 2.2 General OO Concepts ...................................................................................................... 9 2.2.1 Objects and Classes ................................................................................................. 10 2.2.2 Encapsulation........................................................................................................... 10 2.2.3 Inheritance ............................................................................................................... 10 2.2.4 Polymorphism .......................................................................................................... 11 2.2.5 Object Oriented Concepts in Design Patterns ......................................................... 11 2.3 Concurrency ................................................................................................................... 11 2.3.1 Introduction ............................................................................................................. 12 2.3.2 Concurrency Models ................................................................................................ 13 2.4 Erlang ............................................................................................................................. 14 2.4.1 Introduction ............................................................................................................. 15 iii 2.4.2 History and Philosophy ............................................................................................ 15 2.4.3 Programming style ................................................................................................... 16 2.4.4 Sequential Erlang ..................................................................................................... 16 2.4.5 Data Types and Pattern Matching ............................................................................ 17 2.4.6 Concurrent Erlang .................................................................................................... 18 2.4.7 Tail-Recursion ......................................................................................................... 19 2.4.8 Maintaining state ..................................................................................................... 20 2.4.9 Erlang Behaviours ................................................................................................... 21 2.5 Object-Oriented concepts in Erlang ............................................................................... 22 2.5.1 Comparing Erlang to OOP ...................................................................................... 22 2.5.2 Conclusion ............................................................................................................... 25 2.6 Peer-to-Peer ................................................................................................................... 26 2.6.1 Introduction ............................................................................................................. 26 2.6.2 BitTorrent Protocol .................................................................................................. 27 2.7 Conclusion ..................................................................................................................... 28 3. Design Patterns: Design and Implementation as Erlang behaviours ...................................... 30 3.1 Active Object ................................................................................................................. 30 3.1.1 Intent ........................................................................................................................ 31 3.1.2 Context .................................................................................................................... 31 3.1.3 Structure and Dynamics ........................................................................................... 31 3.1.4 Behaviour Implementation ...................................................................................... 33 3.1.5 Usage ....................................................................................................................... 36 3.1.6 Conclusion ............................................................................................................... 37 3.2 Acceptor-Connector ....................................................................................................... 38 3.2.1 Intent ........................................................................................................................ 38 iv 3.2.2 Context .................................................................................................................... 38 3.2.3 Structure & Dynamics ............................................................................................. 38 3.2.4 Behaviour Implementation .....................................................................................
Load more

Recommended publications
  • Applying the Proactor Pattern to High-Performance Web Servers
    APPLYING THE PROACTOR PATTERN TO HIGH-PERFORMANCE WEB SERVERS James Hu Irfan Pyarali Douglas C. Schmidt [email protected],edu [email protected] [email protected] Department of Computer Science, Washington University St. Louis, MO 63130, USA This paper is to appear at the 10th International Confer- 1 INTRODUCTION ence on Parallel and Distributed Computing and Systems, IASTED, Las Vegas, Nevada, October 28-31, 1998. Computing power and network bandwidth on the Internet has increased dramatically over the past decade. High- speed networks (such as ATM and Gigabit Ethernet) and high-performance I/O subsystems (such as RAID) are be- ABSTRACT coming ubiquitous. In this context, developing scalable Web servers that can exploit these innovations remains a Modern operating systems provide multiple concurrency key challenge for developers. Thus, it is increasingly im- mechanisms to develop high-performance Web servers. portant to alleviate common Web server bottlenecks, such Synchronous multi-threading is a popular mechanism for as inappropriate choice of concurrency and dispatching developing Web servers that must perform multiple oper- strategies, excessive filesystem access, and unnecessary ations simultaneously to meet their performance require- data copying. ments. In addition, an increasing number of operating sys- Our research vehicle for exploring the performance im- tems support asynchronous mechanisms that provide the pact of applying various Web server optimization tech- benefits of concurrency, while alleviating much of the per- niques is the JAWS Adaptive Web Server (JAWS) [1]. JAWS formance overhead of synchronous multi-threading. is both an adaptive Web server and a development frame- This paper provides two contributions to the study of work for Web servers that runs on multiple OS platforms high-performance Web servers.
    [Show full text]
  • A Design Framework for Highly Concurrent Systems
    A Design Framework for Highly Concurrent Systems Matt Welsh, Steven D. Gribble, Eric A. Brewer, and David Culler Computer Science Division University of California, Berkeley Berkeley, CA 94720 USA mdw,gribble,brewer,culler @cs.berkeley.edu f g Abstract In addition to high concurrency, Internet services have three other properties which necessitate a fresh Building highly concurrent systems, such as large-scale look at how these systems are designed: burstiness, Internet services, requires managing many information flows continuous demand, and human-scale access latency. at once and maintaining peak throughput when demand ex- Burstiness of load is fundamental to the Internet; deal- ceeds resource availability. In addition, any platform sup- ing with overload conditions must be designed into the porting Internet services must provide high availability and be able to cope with burstiness of load. Many approaches system from the beginning. Internet services must also to building concurrent systems have been proposed, which exhibit very high availability, with a downtime of no generally fall into the two categories of threaded and event- more than a few minutes a year. Finally, because ac- driven programming. We propose that threads and events cess latencies for Internet services are at human scale are actually on the ends of a design spectrum, and that and are limited by WAN and modem access times, an the best implementation strategy for these applications is important engineering tradeoff to make is to optimize somewhere in between. for high throughput rather than low latency. We present a general-purpose design framework for build- ing highly concurrent systems, based on three design com- Building highly concurrent systems is inherently dif- ponents | tasks, queues, and thread pools | which encapsu- ficult.
    [Show full text]
  • Leader/Followers a Design Pattern for Efficient Multi-Threaded I/O
    Leader/Followers A Design Pattern for Efficient Multi-threaded I/O Demultiplexing and Dispatching Douglas C. Schmidt and Carlos O’Ryan g fschmidt,coryan @uci.edu Electrical and Computer Engineering Dept. University of California, Irvine, CA 92697, USA Michael Kircher Irfan Pyarali [email protected] [email protected] Siemens Corporate Technology Department of Computer Science, Washington University Munich, Germany St. Louis, MO 63130, USA 1 Intent The front-end communication servers are actually “hybrid” client/server applications that perform two primary tasks. The Leader/Followers design pattern provides a concurrency First, they receive requests arriving simultaneously from hun- model where multiple threads can efficiently demultiplex dreds or thousands of remote clients over wide area commu- events and dispatch event handlers that process I/O handles nication links, such as X.25 or the TCP/IP. Second, they vali- shared by the threads. date the remote client requests and forward valid requests over TCP/IP connections to back-end database servers. In contrast, the back-end database servers are “pure” servers that perform 2 Example the designated transactions. After a transaction commits, the database server returns its results to the associated commu- Consider the design of a multi-tier, high-volume, on-line trans- nication server, which then forwards the results back to the action processing (OLTP) system shown in the following fig- originating remote client. ure. In this design, front-end communication servers route FRONT--END BACK--END The servers in this OLTP system spend most of their time COMM.. SERVERS DATABASE SERVERS processing various types of I/O operations in response to re- quests.
    [Show full text]
  • Introduction to Patterns and Frameworks
    OO Patterns Douglas C. Schmidt Patterns and Frameworks Introduction to Patterns and Frameworks Motivation for Patterns and Frameworks Douglas C. Schmidt What is a Pattern? A Framework? Professor Department of EECS Pattern Categories [email protected] Vanderbilt University www.cs.wustl.edu/ schmidt/ (615) 343-8197 Pattern Examples Vanderbilt University 1 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Motivation for Patterns and Frameworks Overview of Patterns and Frameworks DX Developing software is hard BLOB Patterns support reuse of software architecture and design STORE Developing reusable – Patterns capture the static and dynamic structures and ATM software is even harder collaborations of successful solutions to problems that arise when LAN DIAGNOSTIC STATIONS building applications in a particular domain Proven solutions include patterns and frameworks Frameworks support reuse of detailed design and code ATM www.cs.wustl.edu/ schmidt/ – A framework is an integrated set of components that collaborate MAN CLUSTER patterns.html to provide a reusable architecture for a family of related ATM BLOB LAN STORE applications Together, design patterns and frameworks help to improve software MODALITIES CENTRAL quality and reduce development time (CT, MR, CR) BLOB STORE – e.g., reuse, extensibility, modularity, performance Vanderbilt University 2 Vanderbilt University 3 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Patterns of Learning Becoming a Chess Master First learn the rules Successful solutions to many areas of human endeavor are deeply rooted in patterns – e.g., names of pieces, legal movements, chess board geometry and orientation, etc. – In fact, an important goal of education is transmitting patterns of learning from generation to generation Then learn the principles – e.g., relative value of certain pieces, strategic value of center In a moment, we’ll explore how patterns are used to learn chess squares, power of a threat, etc.
    [Show full text]
  • Proactor 1 Proactor
    Proactor 1 Proactor The Proactor architecture pattern demultiplexes and dispatches service requests that are triggered by the completion of asynchronous operations. Example Consider a networking application that must perform multiple oper- ations simultaneously. For example, a high-performance Web server must concurrently process HTTP requests sent from multiple remote client Web browsers [HPS99]. When a user wants to download content from a URL, the browser establishes a connection to the Web server and sends an HTTP GET request. The Web server subsequently re- ceives the browser’s CONNECT indication event, accepts the connec- tion, and reads the request. It then parses and validates the request, sends the specified file(s) back to the Web, and closes the connection. 2: parse request 1: HTTP request Web Web Server File Browser System 4: send file 3: read file One way to implement a Web server is to use a reactive event demul- tiplexing model in accordance with the Reactor pattern (75). When a Web browser connects to a Web server, a new event handler is created and registered with a reactor, which coordinates the synchronous de- multiplexing and dispatching of indication events. After the browser’s HTTP GET request arrives, the reactor demultiplexes the associated indication event and calls back to the event handler. The handler then reads, parses, and processes the request and transfers the file back to the browser. Although this model is straightforward to program, however, it does not scale up to support many simultaneous users and/or long-duration user requests because it serializes all HTTP processing at the event demultiplexing layer.
    [Show full text]
  • Applying the Proactor Pattern to High-Performance Web Servers
    APPLYING THE PROACTOR PATTERN TO HIGH-PERFORMANCE WEB SERVERS James Hu Irfan Pyarali Douglas C. Schmidt [email protected],edu [email protected] [email protected] Department of Computer Science, Washington University St. Louis, MO 63130, USA This paper is a revised and expanded version of the paper 1 INTRODUCTION that will appear in the 10th International Conference on Par- allel and Distributed Computing and Systems, IASTED, Las Computing power and network bandwidth on the Internet Vegas, Nevada, October 28-31, 1998. has increased dramatically over the past decade. High-speed networks (such as ATM and Gigabit Ethernet) and high- performance I/O subsystems (such as RAID) are becoming ABSTRACT ubiquitous. In this context, developing scalable Web servers that can exploit these innovations remains a key challenge Modern operating systems provide multiple concurrency for developers. Thus, it is increasingly important to allevi- mechanisms to develop high-performance Web servers. Syn- ate common Web server bottlenecks, such as inappropriate chronous multi-threading is a popular mechanism for devel- choice of concurrency and dispatching strategies, excessive oping Web servers that must perform multiple operations si- filesystem access, and unnecessary data copying. multaneously to meet their performance requirements. In ad- Our research vehicle for exploring the performance impact dition, an increasing number of operating systems support of applying various Web server optimization techniques is the asynchronous mechanisms that provide the benefits of concur- JAWS Adaptive Web Server (JAWS) [1]. JAWS is both an rency, while alleviating much of the performance overhead of adaptive Web server and a development framework for Web synchronous multi-threading.
    [Show full text]
  • 2 Mis on Programmi Ülesehituse Muster?
    TALLINNA ÜLIKOOL Informaatika osakond PROGRAMMI ÜLESEHITUSE MUSTRID Seminaritöö Üliõpilane: Margo Poolak Juhendaja: Jaagup Kippar Tallinn 2006 Sisukord 1 Sissejuhatus . .4 2 Mis on programmi ülesehituse muster? . .4 3 Programmi ülesehituse mustri dokumenteerimine . .5 4 Tutvustavate programmi mustrite valik . .5 4.1 Loomise seaduspärasus (Creational patterns) ............................................................................... .6 4.1.1 Lazy initialization pattern . .6 4.1.2 Anonymous subroutine objects pattern . .8 4.1.3 Abstract factory pattern . .10 4.1.4 Builder pattern ............................................................................ .12 4.1.5 Factory method pattern . .14 4.1.6 Prototype pattern . .15 4.1.7 Singleton pattern . .16 4.2 Struktureeritud mustrid (Structural patterns) . .17 4.2.1 Adapter pattern . .17 4.2.2 Bridge pattern ......................................... .18 4.2.3 Composite pattern . .19 4.2.4 Decorator pattern ........................................................................ .20 4.2.5 Facade pattern . .21 4.2.6 Flyweight pattern . .22 4.2.7 Proxy pattern . .23 4.3 Käitumuslikud mustrid (Behavioral patterns) . .24 4.3.1 Chain of responsibility pattern . .24 4.3.2 Command pattern . .25 4.3.3 Interpreter pattern ............................. .26 4.3.4 Iterator pattern . .26 4.3.5 Mediator pattern . .27 4.3.6 Memento pattern . .28 4.3.7 Observer pattern . .29 4.3.8 State pattern ................................................................................ .30 4.3.9 Strategy pattern . .30 4.3.10 Template method pattern . .31 4.3.1 1 Visitor pattern . .35 4.4 Fundamentaalsed mustrid (Fundamental patterns) . .37 4.4.1 Delegation pattern . .37 4.4.2 Functional design . .37 4.4.3 Interface pattern . .37 4.4.4 Proxy pattern . .37 4.4.5 Immutable pattern . .37 4.4.6 Marker interface pattern .
    [Show full text]
  • Introduction to Patterns and Frameworks  What Is a Pattern? a Framework?
    Dr. David L. Levine CS 342: Patterns and Frameworks Introduction Patterns and Frameworks CS 342: Object-Oriented Software Development Lab Motivation for Patterns and Frameworks Introduction to Patterns and Frameworks What is a Pattern? A Framework? Pattern Categories Dr. David L. Levine and Douglas C. Schmidt Department of Computer Science Pattern Examples Washington University, St. Louis flevine,[email protected] http://classes.cec.wustl.edu/cs342/ Department of Computer Science 1 Washington University, St. Louis Dr. David L. Levine CS 342: Patterns and Frameworks Introduction Dr. David L. Levine CS 342: Patterns and Frameworks Introduction Motivation for Patterns and Frameworks Overview of Patterns and Frameworks Patterns support reuse of software architecture and design Developing software is hard – Patterns capture the static and dynamic structures and Developing reusable software is even harder collaborations of successful solutions to problems that arise when Proven solutions include patterns and frameworks building applications in a particular domain Frameworks support reuse of detailed design and code – A framework is an integrated set of components that collaborate to provide a reusable architecture for a family of related applications. Together, design patterns and frameworks help to improve software quality and reduce development time – e.g., reuse, extensibility, modularity, performance Department of Computer Science 2 Washington University, St. Louis Department of Computer Science 3 Washington University, St. Louis Dr. David L. Levine CS 342: Patterns and Frameworks Introduction Dr. David L. Levine CS 342: Patterns and Frameworks Introduction Patterns of Learning Becoming a Chess Master First learn rules and physical requirements Successful solutions to many areas of human endeavor are deeply rooted in patterns – e.g., names of pieces, legal movements, chess board geometry and orientation, etc.
    [Show full text]
  • Pattern-Oriented Software Architecture, Volume 2.Pdf
    Pattern-Oriented Software Architecture, Patterns for Concurrent and Networked Objects, Volume 2 by Douglas Schmidt, Michael Stal, Hans Rohnert and Frank Buschmann ISBN: 0471606952 John Wiley & Sons © 2000 (633 pages) An examination of 17 essential design patterns used to build modern object- oriented middleware systems. 1 Table of Contents Pattern-Oriented Software Architecture—Patterns for Concurrent and Networked Objects, Volume 2 Foreword About this Book Guide to the Reader Chapter 1 - Concurrent and Networked Objects Chapter 2 - Service Access and Configuration Patterns Chapter 3 - Event Handling Patterns Chapter 4 - Synchronization Patterns Chapter 5 - Concurrency Patterns Chapter 6 - Weaving the Patterns Together Chapter 7 - The Past, Present, and Future of Patterns Chapter 8 - Concluding Remarks Glossary Notations References Index of Patterns Index Index of Names 2 Pattern-Oriented Software Architecture—Patterns for Concurrent and Networked Objects, Volume 2 Douglas Schmidt University of California, Irvine Michael Stal Siemens AG, Corporate Technology Hans Rohnert Siemens AG, Germany Frank Buschmann Siemens AG, Corporate Technology John Wiley & Sons, Ltd Chichester · New York · Weinheim · Brisbane · Singapore · Toronto Copyright © 2000 by John Wiley & Sons, Ltd Baffins Lane, Chichester, West Sussex PO19 1UD, England National 01243 779777 International (+44) 1243 779777 e-mail (for orders and customer service enquiries): <[email protected]> Visit our Home Page on http://www.wiley.co.uk or http://www.wiley.com All rights reserved.
    [Show full text]
  • Applying Patterns and Frameworks to Develop Object-Oriented Communication Software
    Applying Patterns and Frameworks to Develop Object-Oriented Communication Software Douglas C. Schmidt [email protected] Department of Computer Science Washington University, St. Louis, MO 63130 This paper appeared in the Handbook of Programming from network and host failures, minimizing the impact of com- Languages, Volume I, edited by Peter Salus, MacMillan Com- munication latency, and determining an optimal partitioning of puter Publishing, 1997. application service components and workload onto processing elements throughout a network. The accidental complexities associated with communica- 1 Introduction tion software stem from limitations with conventional tools and techniques. For instance, low-level network programming Communication software for next-generation distributed ap- interfaces like Sockets are tedious and error-prone. Likewise, plications must be flexible and efficient. Flexibility is needed higher-level distributed computing middleware like CORBA, to support a growing range of multimedia datatypes, traf- DCOM, and Java RMI lack key features, such as asynchronous fic patterns, and end-to-end quality of service (QoS) require- I/O and end-to-end QoS guarantees. Moreover, conventional ments. Efficiency is needed to provide low latency to delay- higher-level middleware implementations are not yet opti- sensitive applications (such as avionics and call processing) mized for applications with stringent performance require- and high performance to bandwidth-intensive applications ments [2, 3]. (such as medical imaging and teleconferencing) over high- Another source of accidental complexity arises from the speed and mobile networks. widespread use of algorithmic design [4] to develop commu- This paper outlines the key sources of complexity for com- nication software. Although graphical user-interfaces (GUIs) munication software and describes how patterns and frame- are largely built using object-oriented (OO) design, commu- works can alleviate much of this complexity.
    [Show full text]
  • Proactor 1 Intent 2 Motivation
    Proactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handlers for Asynchronous Events Irfan Pyarali, Tim Harrison, and Douglas C. Schmidt Thomas D. Jordan 1 g firfan, harrison, schmidt @cs.wustl.edu [email protected] Dept. of Computer Science SoftElegance Washington University 2 Hartford, WI 53027 St. Louis, MO 63130, (314) 935-7538 (414) 673-9813 th This paper appeared at the 4 annual Pattern Languages 2 Motivation of Programming conference held in Allerton Park, Illinois, September, 1997. This section provides the context and motivation for using the Proactor pattern. Abstract 2.1 Context and Forces Modern operating systems provide multiple mechanisms for The Proactor pattern should be applied when applications developing concurrent applications. Synchronous multi- require the performance benefits of executing operations threading is a popular mechanism for developing applica- concurrently, without the constraints of synchronous multi- tions that perform multiple operations simultaneously. How- threaded or reactive programming. To illustrate these ben- ever, threads often have high performance overhead and re- efits, consider a networking application that needs to per- quire deep knowledge of synchronization patterns and prin- form multiple operations concurrently. For example, a high- ciples. Therefore, an increasing number of operating systems performance Web server must concurrently process HTTP support asynchronous mechanisms that provide the benefits requests sent from multiple clients [1, 2]. Figure 1 shows a of concurrency while alleviating much of the overhead and typical interaction between Web browsers and a Web server. complexity of multi-threading. When a user instructs a browser to open a URL, the browser The Proactor pattern presented in this paper describes how to structure applications and systems that effectively uti- lize asynchronous mechanisms supported by operating sys- tems.
    [Show full text]
  • Pyarali.Proactor.Pdf
    Proactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handlers for Asynchronous Events Irfan Pyarali, Tim Harrison, and Douglas C. Schmidt Thomas D. Jordan 1 g firfan, harrison, schmidt @cs.wustl.edu [email protected] Dept. of Computer Science SoftElegance Washington University, St. Louis2 Hartford, WI 53027 St. Louis, MO 63130, (314) 935-7538 (414) 673-9813 th This paper will appear at the 4 annual Pattern Languages 2 Motivation of Programming conference held in Allerton Park, Illinois, September, 1997. Permission is granted to make copies of This section provides the context and motivation for using this paper for the PLoP ’97 conference proceedings. the Proactor pattern. 2.1 Context and Forces Abstract The Proactor pattern should be applied when applications re- Modern operating systems provide multiple mechanisms for quire the performance benefits of executing operations con- developing concurrent applications. Synchronous multi- currently, without being constrained by synchronous multi- threading is a popular mechanism for developing applica- threaded or reactive programming. To illustrate this, con- tions that perform multiple operations simultaneously. How- sider networking applications that need to perform multiple ever, threads often have high performance overhead and re- operations concurrently. For example, a high-performance quire deep knowledge of synchronization patterns and prin- Web server must concurrently process HTTP requests sent ciples. Therefore, an increasing number of operating systems from multiple clients [1]. Figure 1 shows a typical inter- support asynchronous mechanisms that provide the benefits action between Web browsers and a Web server. When a of concurrency while alleviating much of the overhead and user instructs a browser to open a URL, the browser sends complexity of multi-threading.
    [Show full text]