DOCSLIB.ORG

Applying the Proactor Pattern to High-Performance Web Servers

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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 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. First, it examines how syn- including Win32, most versions of UNIX, and MVS Open chronous and asynchronous event dispatching mechanisms Edition. impact the design and performance of JAWS, which is our Our experience [2] building Web servers on multiple OS high-performance Web server framework. The results re- platforms demonstrates that the effort required to optimize veal significant performance improvements when a proac- performance can be simplified significantly by leveraging tive concurrency model is used to combine lightweight con- OS-specific features. For example, an optimized file I/O currency with asynchronous event dispatching. system that automatically caches open files in main mem- In general, however, the complexity of the proactive con- ory via mmap greatly reduces latency on Solaris. Like- currency model makes it harder to program applications wise, support for asynchronous event dispatching on Win- that can utilize asynchronous concurrency mechanisms ef- dows NT can substantially increase server throughput by fectively. Therefore, the second contribution of this paper reducing context switching and synchronization overhead describes how to reduce the software complexity of asyn- incurred by multi-threading. chronous concurrent applications by applying the Proactor Unfortunately, the increase in performance obtained pattern. This pattern describes the steps required to struc- through the use of asynchronous event dispatching on ex- ture object-oriented applications that seamlessly combine isting operating systems comes at the cost of increased concurrency with asynchronous event dispatching. The software complexity. Moreover, this complexity is fur- Proactor pattern simplifies concurrent programming and ther compounded when asynchrony is coupled with multi- improves performance by allowing concurrent application threading. This style of programming, i.e., proactive pro- to have multiple operations running simultaneously with- gramming, is relatively unfamiliar to many developers ac- out requiring a large number of threads. customed to the synchronous event dispatching paradigm. This paper describes how the Proactor pattern can be This work was supported in part by Siemens Med and Siemens Cor- applied to improve both the performance and the design porate Research. of high-performance communication applications, such as 1 Web servers. Strategy, I/O Strategy, Protocol Pipeline, Protocol Han- A pattern represents a recurring solution to a software dlers,andCached Virtual Filesystem. Each framework is development problem within a particular context [3]. Pat- structured as a set of collaborating objects implemented us- terns identify the static and dynamic collaborations and in- ing components in ACE [5]. The collaborations among teractions between software components. In general, ap- JAWS components and frameworks are guided by a family plying patterns to complex object-oriented concurrent ap- of patterns, which are listed along the borders in Figure 1. plications can significantly improve software quality, in- An outline of the key frameworks, components, and pat- crease software maintainability, and support broad reuse terns in JAWS is presented below; Section 4 then focuses of components and architectural designs [4]. In particu- on the Proactor pattern in detail.1 lar, applying the Proactor pattern to JAWS simplifies asyn- chronous application development by structuring the de- Event Dispatcher: This component is responsible for co- multiplexing of completion events and the dispatching of ordinating JAWS’ Concurrency Strategy with its I/O Strat- their corresponding completion routines. egy. The passive establishment of connection events with The remainder of this paper is organized as follows: Sec- Web clients follows the Acceptor pattern [6]. New incom- tion 2 provides an overview of the JAWS server framework ing HTTP request events are serviced by a concurrency design; Section 3 discusses alternative event dispatching strategy. As events are processed, they are dispatched to strategies and their performance impacts; Section 4 ex- the Protocol Handler, which is parameterized by an I/O plores how to leverage the gains of asynchronous event dis- strategy. JAWS ability to dynamically bind to a particu- patching through application of the Proactor pattern; and lar concurrency strategy and I/O strategy from a range of Section 5 presents concluding remarks. alternatives follows the Strategy pattern [3]. Concurrency Strategy: This framework implements con- 2 JAWS FRAMEWORK OVERVIEW currency mechanisms (such as single-threaded, thread-per- request, or thread pool) that can be selected adaptively at Figure 1 illustrates the major structural components and run-time using the State pattern [3] or pre-determined at design patterns that comprise the JAWS framework [1]. initialization-time. The Service Configurator pattern [7] is JAWS is designed to allow the customization of various used to configure a particular concurrency strategy into a Web server at run-time. When concurrency involves multi- Reactor/Proactor Strategy Singleton ple threads, the strategy creates protocol handlers that fol- Memento I/O Strategy Cached Virtual low the Active Object pattern [8]. Framework Filesystem State I/O Strategy: This framework implements various I/O mechanisms, such as asynchronous, synchronous and re- Asynchronous Completion Token Tilde ~ active I/O. Multiple I/O mechanisms can be used simulta- Expander /home/... Protocol Acceptor neously. In JAWS, asynchronous I/O is implemented using Event Dispatcher Handler the Proactor pattern [9], while reactive I/O is accomplished Protocol through the Reactor pattern [10]. These I/O strategies may Filter utilize the Memento [3] and Asynchronous Completion To- Service Configurator Service Configurator ken [11] patterns to capture and externalize the state of a Adapter request so that it can be restored at a later time. Concurrency Protocol Pipeline Strategy Protocol Handler: This framework allows system devel- Framework Framework State opers to apply the JAWS framework to a variety of Web Pipes and Filters Active Object Strategy system applications. A Protocol Handler is parameter- ized by a concurrency strategy and an I/O strategy. These strategies are decoupled from the protocol handler using Figure 1: Architectural Overview of the JAWS Framework the Adapter pattern [3]. In JAWS, this component imple- Web server strategies in response to environmental factors. ments the parsing and handling of HTTP/1.0 request meth- These factors include static factors (e.g., number of avail- ods. The abstraction allows for other protocols (such as able CPUs, support for kernel-level threads, and availabil- HTTP/1.1, DICOM, and SFP [12]) to be incorporated eas- ity of asynchronous I/O in the OS), as well as dynamic fac- ily into JAWS. To add a new protocol, developers simply tors (e.g., Web traffic patterns and workload characteris- write a new Protocol Handler implementation, which is tics). then configured into the JAWS framework. JAWS is structured as a framework of frameworks.The 1Due to space limitations it is not possible to describe all the patterns overall JAWS framework contains the following compo- mentioned below in detail. The references provide complete coverage of nents and frameworks: an Event Dispatcher, Concurrency each pattern, however. 2 Protocol Pipeline: This framework allows filter operations Efficiency: The server must minimize latency, maximize to be incorporated easily with the data being processed by throughput, and avoid utilizing the CPU(s) unnecessarily. the Protocol Handler. This integration is achieved by em- Adaptability: Integrating new or improved transport
Load more

Recommended publications
  • 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]
  • Application of Patterns to Real-Time Object-Oriented Software Design
    APPLICATION OF PATTERNS TO REAL-TIME OBJECT-ORIENTED SOFTWARE DESIGN by ROSS ALBERT MCKEGNEY A thesis submitted to the Department of Computing & Information Science in conformity with the requirements for the degree of Master of Science Queen’s University, Kingston, Ontario Canada July 2000 Copyright © Ross Albert McKegney, 2000 ABSTRACT The design and development of real-time software (i.e. software that must ensure timeliness while interacting with an external environment) is more difficult than for most other software. Modeling tools help deal with this complexity, allowing developers to view the system at various levels of abstraction, animate the models in a simulation environment, and even generate the code for a variety of target hardware/RTOS configurations. A natural extension to these tools is to provide support for design patterns (a method of documenting experience in the form of problem/context/solution triples for recurring problems). Such an extension provides yet another layer of abstraction to the models, and makes explicit the application of design patterns. This thesis will extract from the patterns literature a set of patterns dealing with issues relevant to the design of real-time object-oriented software (in order to demonstrate their variety and quality) - then will propose an extension to Rational Rose-RT to support patterns as an abstraction layer. ii ACKOWLEDGMENTS I would like to acknowledge my supervisor, Dr. Terry Shepard, for his guidance and direction throughout the writing of this thesis. I also acknowledge the members of my ‘hot-topics’ group at ChiliPLoP 2000: Mary-Lynn Manns (UNCS), Linda Rising (AGCS), Don Olson (AGCS), John Letourneau (Lucent Technologies), and Carol Stimmel (MediaOne Labs) for introducing me to pattern writing workshops.
    [Show full text]