Motivation for Concurrency Object-Oriented Design Patterns Concurrent programming is increasing rele- vant to: for Network Programming in { Leverage hardware/software advances C++ . e.g., multi-pro cessors and OS thread supp ort { Increase p erformance Douglas C. Schmidt . e.g., overlap computation and communication Washington University, St. Louis { Improve resp onse-time . e.g., GUIs and network servers http://www.cs.wustl.ed u/s chmi dt/ { Simplify program structure [email protected] u . e.g., synchronous vs. asynchronous network IPC 1 2 Challenges and Solutions Motivation for Distributi on However, developing ecient, robust, and extensible concurrent networking applications is hard Bene ts of distributed computing: { e.g., must address complex topics that are less problematic or not relevant for non-concurrent, { Collab oration ! connectivity and interworking stand-alone applications { Performance ! multi-pro cessing and lo cality Object-oriented OO techniques and OO { Reliability and availability ! replication language features help to enhance concur- rent software quality factors { Scalability and p ortability ! mo dularity { Key OO techniques include design patterns and frameworks { Extensibility ! dynamic con guration and recon- guration { Key OO language features include classes, inheri- tance, dynamic binding, and parameterized typ es { Cost e ectiveness ! op en systems and resource sharing { Key software quality factors include mo dularity, extensibility, portability, reusability, and correct- ness 3 4 Caveats Tutorial Outline OO is not a panacea { However, when used prop erly it helps minimize Outline key OO networking and concurrency \accidental" complexity and improve software qual- concepts and OS platform mechanisms ity factors { Emphasis is on practical solutions Advanced OS features provide additional func- tionality and p erformance, e.g., Examine several examples in detail { Multi-threading 1. Concurrent WWW client/server { Multi-pro cessing 2. OO framework forlayered active objects { Synchronization { Shared memory Discuss general concurrent programming strate- gies { Explicit dynamic linking { Communication proto cols and IPC mechanisms 6 5 De nitions Software Development Concurrency Environment { \Logically" simultaneous pro cessing The topics discussed here are largely inde- { Do es not imply multiple pro cessing elements p endent of OS, network, and programming language { Currently used successfully on UNIX and Windows Parallelism NT platforms, running on TCP/IP and IPX/SPX networks, using C++ { \Physically" simultaneous pro cessing { Involves multiple pro cessing elements and/or inde- p endent device op erations Examples are illustrated using freely avail- able ADAPTIVE Communication Environ- ment ACE OO framework comp onents Distribution { Although ACE is written in C++, the principles covered in this tutorial apply to other OO lan- guages { Partition system/application into multiple comp o- nents that can reside on di erent hosts . e.g., Java, Ei el, Smalltalk, etc. { Implies message passing as primary IPC mecha- nism 7 8 Concurrency vs. Parallelism Stand-alone vs. Distribut ed Application Architectures SERVER PRINTER maxfdp1 read_fds COMPUTER CLIENT WORK REQUEST FILE CD ROM SYSTEM WORK WORK WORK CLIENT REQUEST REQUEST REQUEST (1) STAND-ALONE APPLICATION ARCHITECTURE CLIENT CLIENT TIME NAME SERVICE CYCLE CONCURRENT SERVER SERVICE SERVICE DISPLAY SERVER SERVICE FI LE CPU1 CPU2 CPU3 CPU4 NETWORK SERVICE CLIENT PRINT WORK SERVICE REQUEST CD ROM WORK PRINTER WORK WORK FILE SYSTEM CLIENT REQUEST REQUEST REQUEST (2) DISTRIBUTED APPLICATION ARCHITECTURE CLIENT CLIENT PARALLEL SERVER 9 10 Sources of Complexity Sources of Complexity cont'd Concurrent network application development Accidental complexity results from limi ta- tions with to ols and techniques used to de- exhibits b oth inherent and accidental com- velop concurrent applications, e.g., plexity { Lack of p ortable, reentrant, typ e-safe and extensi- ble system call interfaces and comp onent libraries Inherent complexity results from fundamen- tal challenges { Inadequate debugging supp ort and lack of concur- rent and distributed program analysis to ols { Concurrent programming * Eliminating \race conditions" { Widespread use of algorithmic decomp osition * Deadlo ck avoidance *Fair scheduling . Fine for explaining concurrent programming con- *Performance optimization and tuning cepts and algorithms but inadequate for develop- ing large-scale concurrent network applications { Distributed programming * Addressing the impact of latency { Continuous rediscovery and reinvention of core con- *Fault tolerance and high availability cepts and comp onents * Load balancing and service partitioning * Consistent ordering of distributed events 11 12 OO Contribution s to Concurrent Application s Design Patterns UNIX concurrent network programming has Design patterns represent solutions to prob- traditionally b een p erformed using low-level lems that arise when developing software OS mechanisms, e.g., within a particular context * fork/exec { i.e.,\Patterns == problem/solution pairs in a con- * Shared memory, mmap, and SysV semaphores text" * Signals * so ckets/select * POSIX pthreads and Solaris threads Patterns capture the static and dynamic struc- ture and collab oration among key partici- OO design patterns and frameworks elevate pants in software designs development to fo cus on application con- cerns, e.g., { They are particularly useful for articulating how and why to resolve non-functional forces { Service functionality and p olicies { Service con guration Patterns facilitate reuse of successful soft- { Concurrent event demultiplexing and event han- ware architectures and designs dler dispatching { Service concurrency and synchronization 14 13 Active Object Pattern Collab orati on in the Active loop { Pattern Client m = actQueue.remove() Object Interface dispatch (m) } ResultHandle m1() ResultHandle m2() Scheduler t1 : t2 : t2msg_q : t3 : ResultHandle m3() Task Task Message_Queue Task dispatch() Activation work() m1'() PRODUCER TASK m2'() 1 Queue PHASE VISIBLE m3'() 1 PRODUCER insert() put(msg) TO PASS MSG remove() CLIENTS 1 enqueue_tail(msg) 1 ENQUEUE MSG () 1 n RUN SVC svc() INVISIBLE ASYNCHRONOUSLY TO Resource PHASE dequeue_head(msg) Method QUEUEING CLIENTS Representation Objects DEQUEUE MSG CONSUMER TASK work() PHASE PASS MSG put(msg) CONSUMER Intent: decouples the thread of metho d ex- ecution from the thread of metho d invo ca- tion 15 16 Frameworks Di erences Between Class Libraries and Frameworks A framework is: \An integrated collection of comp onents that col- { APPLICATION NETWORKING rate to pro duce a reusable architecture for a lab o SPECIFIC family of related applications" LOGIC INVOKES MATH ADTS EVENT USER DATA LOOP INTERFACE Frameworks di er from conventional class BASE libraries: CLASS Frameworks are \semi-complete" applications 1. LIBRARIES 2. Frameworks address a particular application do- main NETWORKING MATH USER INTERFACE Frameworks provide \inversion of control" 3. APPLICATION CALL INVOKES SPECIFIC BACKS LOGIC EVENT LOOP ADTS DATABASE Typically, applications are develop ed by in- from and instantiating framework heriting OBJECT-ORIENTED FRAMEWORK comp onents 17 18 The ADAPTIVE Communication Class Categories in ACE Environment ACE APPLICATION- APPLICATIONS APPLICATIONS DISTRIBUTED SPECIFIC SERVICES AND GATEWAY TOKEN LOGGING NAME TIME APPLICATIONS COMPONENTS SERVER SERVER SERVER SERVER SERVER FRAMEWORKS SERVICE CORBA ACCEPTOR CONNECTOR AND CLASS HANDLER HANDLER Network CATEGORIES ADAPTIVE SERVICE EXECUTIVE (ASX) Services Stream C++ THREAD LOG SERVICE SHARED APPLICATION- MANAGER MSG CONFIG- MALLOC WRAPPERS Framework REACTOR URATOR SYNCH SPIPE SOCK_SAP/ FIFO MEM SYSV INDEPENDENT WRAPPERS SAP TLI_SAP SAP MAP WRAPPERS OS ADAPTATION LAYER Service C THREAD STREAM SOCKETS/ NAMED SELECT/ DYNAMIC MEMORY SYSTEM Initialization APIS LIBRARY PIPES TLI PIPES POLL LINKING MAPPING V IPC PROCESS/THREAD COMMUNICATION VIRTUAL MEMORY Interprocess SUBSYSTEM SUBSYSTEM SUBSYSTEM GENERAL POSIX AND WIN32 SERVICES Communication Service Configurator Reactor Concurrency global A set of C++ wrapp ers, class categories, and frameworks based on design patterns 19 20 Class Categories in ACE cont'd Resp onsibilities of each class category Concurrency Overview { IPC encapsulates lo cal and/or remote IPC mech- anisms A thread of control is a single sequence of { Service Initialization encapsulates active/passive execution steps p erformed in one or more connection establishment mechanisms programs { Concurrency encapsulates and extends multi-threading { One program ! standalone systems and synchronization mechanisms { More than one program ! distributed systems { Reactor p erforms event demultiplexing and event handler dispatching Traditional OS pro cesses contain a single { Service Configurator automates con guration thread of control and recon guration by encapsulating explicit dy- namic linking mechanisms { This simpli es programming since a sequence of execution steps is protected from unwanted inter- { Stream Framework mo dels and implements layers ference by other execution sequences::: and partitions of hierarchically-integrated commu- nication software { Network Services provides distributed naming, logging, lo cking, and routing services 22 21 Traditional Approaches to OS Evaluating Traditional OS Concurrency Pro cess-based Concurrency 1. Device drivers and programs with signal han- Advantages dlers utilize a limit