POSA 2 Patterns PATTERNORIENTED SOFTWARE ARCHITECTURE Patterns for

POSA 2 Patterns PATTERN-ORIENTED SOFTWARE ARCHITECTURE Patterns for concurrent and networked objects POSA 2 – © François Guibault – e. NGenuity – 2005

POSA 2 Patterns Outline Ø Motivation Ø Four challenges in distributed software design Ø Design patterns for distributed software § § Service access and configuration Event handling Synchronization Concurrency A&D 2005 – © François Guibault – e. NGenuity – 2005 2

POSA 2 Patterns Reference This discussion is almost entirely based on : D. Schmidt, M. Stal, H. Rohnert and F. Buschmann. “Pattern-Oriented Software Architecture – Patterns for Concurrent and Networked Objects”. Wiley series in Software Design Patterns, John Wiley & Sons Ltd, 2000, 633 pages. A&D 2005 – © François Guibault – e. NGenuity – 2005 3

POSA 2 Patterns Motivation Modern software development does not deal with a single process on a single CPU anymore : – Distributed applications are everywhere, – Network use, speed and access is constantly increasing, – Multi-threaded applications are common place – Multi-processor machines are becoming widely available A&D 2005 – © François Guibault – e. NGenuity – 2005 4

POSA 2 Patterns Motivation Expected benefits of distributed applications include : Ø Collaboration and connectivity : accessing an ever wider range of geographically distributed information and services, Ø Enhanced performance, scalability and fault tolerance, Ø Cost effectiveness through sharing of scarce or expensive resources. A&D 2005 – © François Guibault – e. NGenuity – 2005 5

POSA 2 Patterns Motivation Ø Software development is complex, but distributed, multi-threaded software development is really hard – Partial service failures, distributed deadlocks, Qo. S requirements, – Limits in software tools and development techniques (APIs, debuggers, dated programming paradigms), – Limits in software development processes, – Continuous re-invention and re-discovery of fundamental concepts and techniques. A&D 2005 – © François Guibault – e. NGenuity – 2005 6

POSA 2 Patterns Motivation Some of the issues that must be dealt with in distributed software : – – – Connection establishment and service initialization, Event demultiplexing and event handler dispatching, Interprocess communication and network protocols, Multilevel storage management and caching, Component configuration, Concurrency and synchronization A&D 2005 – © François Guibault – e. NGenuity – 2005 7

POSA 2 Patterns Motivation Ø Pattern based software development approaches have proven invaluable for the development of standard single-threaded, single process software, Ø Patterns provide : – Common vocabulary for developers to communicate, – Sharing of proven adaptable solutions to frequent design problems – Re-use of design solution rather than re-use of code A&D 2005 – © François Guibault – e. NGenuity – 2005 8

POSA 2 Patterns Challenges Ø Four challenges in distributed software design § § Service access and configuration Synchronization Concurrency Event handling A&D 2005 – © François Guibault – e. NGenuity – 2005 9

POSA 2 Patterns Challenge 1 – Service access and configuration Ø Distributed services can be accessed using network APIs at various levels of abstraction : – IPC calls involving shared memory and sockets, – Communication protocols such as TELNET, FTP, SSH, etc. – Remote method invocations using application level service components and communication middleware such as COM+, CORBA or JAVA-RMI. A&D 2005 – © François Guibault – e. NGenuity – 2005 10

POSA 2 Patterns Challenge 1 – Service access and configuration ØProviding support for static and dynamic evolution of services involves managing the : – Evolution of interfaces and relationships among service components, – Dynamic reconfiguration of service load to better map with available processing power, ØIdeally without impacting on the clients A&D 2005 – © François Guibault – e. NGenuity – 2005 11

POSA 2 Patterns Challenge 2 – Synchronization Ø The need to correctly synchronize access to shared resources carries its own set of design issues, including providing : – Adequate acquisition and release of locks, – Flexibility in the choice of synchronization mechanism, – Minimization of locking overhead and prevention of self-deadlock in intra-component method calls, – Reduced contention and overhead for rarely executed critical sections. A&D 2005 – © François Guibault – e. NGenuity – 2005 12

POSA 2 Patterns Challenge 3 – Concurrency Ø Allowing multiple threads and processes to simultaneously execute and share resources requires to deal with common concurrency hazards such as : – Race conditions and deadlocks Ø But also involves dealing with : – Non portable multi-threading and multi-processing APIs, – Discrepancies in thread semantic among OS’s A&D 2005 – © François Guibault – e. NGenuity – 2005 13

POSA 2 Patterns Challenge 3 – Concurrency Ø Fundamental concurrent system design issues include : – Determining an efficient application concurrency architecture that minimizes overhead, – Efficiently combining synchronous and asynchronous processing tasks, – Selecting appropriate synchronization primitives, – Eliminating unnecessary threads and locks in concurrent and real-time applications. A&D 2005 – © François Guibault – e. NGenuity – 2005 14

POSA 2 Patterns Challenge 4 – Event handling Three important characteristics differentiate eventdriven applications from applications with selfdirected flow of control : 1. Application behavior is triggered by internal and external events that occur asynchronously, 2. Most events must be handled promptly to prevent CPU starvation and perceived response time, 3. Finite state machines may be needed to control event processing and detect illegal transitions. A&D 2005 – © François Guibault – e. NGenuity – 2005 15

POSA 2 Patterns Service access and configuration patterns 1. 2. 3. 4. Wrapper Façade Component configurator Interceptor Extension Interface A&D 2005 – © François Guibault – e. NGenuity – 2005 16

POSA 2 Patterns Wrapper Façade Pattern Intent Encapsulate the functions and data provided by existing non-objectoriented APIs within more concise, robust, portable, maintainable and cohesive object-oriented class interfaces. Applicability Wrapper façade is applicable whenever a set of mature C libraries providing well defined behavior must be interfaced with object-oriented C++ code. Wrapper Façade is often applied to improve application portability by ‘wrapping’ lower-level operating system APIs. A&D 2005 – © François Guibault – e. NGenuity – 2005 17

POSA 2 Patterns Wrapper Façade Pattern Structure Client calls methods calls Wrapper. Facade data method 1() method. N() calls API Function. A() API Function. B() API Function. C() calls void method 1() { function. A(); function. B(); } A&D 2005 – © François Guibault – e. NGenuity – 2005 18

POSA 2 Patterns Wrapper Façade Pattern Consequences + Concise, cohesive and robust higher-level object-oriented programming interfaces, + Portability and maintainability, + Enhanced modularity and reusability, - Loss of functionality, - Performance degradation (e. g. if implemented as a bridge), - Programming language and compiler limitations. A&D 2005 – © François Guibault – e. NGenuity – 2005 19

POSA 2 Patterns Component configurator Pattern Intent Allow an application to link and unlink its component implementations at run-time without having to modify, recompile or statically relink the application. Component configuration further supports the reconfiguration of components into different application processes without having to shut down and re-start running processes. Applicability This pattern is applicable when a component needs to dynamically change the way it is implemented but one does not want to commit all possible configurations to memory at application startup. The component configurator allows to load a specific component configuration only when it is needed, and when it is needed. A&D 2005 – © François Guibault – e. NGenuity – 2005 20

POSA 2 Patterns Component configurator Pattern Structure Component repository Component configurator Component Concrete Component. A Concrete Component. B A&D 2005 – © François Guibault – e. NGenuity – 2005 21

POSA 2 Patterns Component configurator Pattern Consequences + + + - Uniformity of configuration and control interface, Centralized administration, Enhanced modularity, testability and reusability, Configuration dynamism and control, Increased tuning through wider configuration possibilities, Lack of determinism through possible interactions between dynamically configured components, - Reduced security or reliability, - Increased run-time overhead and infrastructure complexity, - Overly narrow common interfaces. A&D 2005 – © François Guibault – e. NGenuity – 2005 22

POSA 2 Patterns Interceptor Pattern Intent The interceptor allows services to be added transparently to a framework and triggered automatically when certain events occur. Applicability This pattern is applicable when a framework must be able to register and trigger new services that where not initially planed for, and let applications using the framework access and control certain aspects of the framework behavior. A&D 2005 – © François Guibault – e. NGenuity – 2005 23

POSA 2 Patterns Interceptor Pattern Structure create Concrete Framework Context * 1. . * Dispatcher register remove Application Interceptor Concrete Interceptor A&D 2005 – © François Guibault – e. NGenuity – 2005 use 24

POSA 2 Patterns Interceptor Pattern Consequences + + + - Increases Framework extensibility and flexibility, Promotes separation of concerns between services, Support for monitoring and control of frameworks, Layer symmetry, Reusability of interceptors, Difficulty in anticipating events to be intercepted and separating among interceptor interfaces, - Malicious or erroneous interceptors, - Potential interception cascades through context-based changes to the framework. A&D 2005 – © François Guibault – e. NGenuity – 2005 25

POSA 2 Patterns Extension interface Pattern Intent Allow multiple interfaces to be exported by a component, to prevent bloating of interfaces and breaking of client code when developers extend or modify the functionality of a component. Applicability Whenever it can be anticipated that component interfaces may need to evolve in unanticipated ways after the component’s release and integration into applications. When existing clients should not be affected by the addition of new interfaces to accommodate the needs of new clients. A&D 2005 – © François Guibault – e. NGenuity – 2005 26

POSA 2 Patterns Extension interface Pattern Structure Root Interface get. Extension() invoke Extension Interface Client service() 1. . * instantiate Component Factory new Component service() A&D 2005 – © François Guibault – e. NGenuity – 2005 27

POSA 2 Patterns Extension interface Pattern Consequences + + + - Provides component’s extensibility mechanisms, Promotes separation of concerns between roles, Supports polymorphism of hierarchically unrelated classes, Decouples components from their clients, Support for interface aggregation and delegation, Increased component design and implementation effort, Increased client programming complexity, Additional indirection and run-time overhead. A&D 2005 – © François Guibault – e. NGenuity – 2005 28

POSA 2 Patterns Synchronization patterns 1. 2. 3. 4. Scoped locking Strategized locking Thread-safe Interface Double-Checked Locking Optimization A&D 2005 – © François Guibault – e. NGenuity – 2005 29

POSA 2 Patterns Scoped locking Pattern Intent Ensure that a lock is acquired when control enters a scope and released automatically when control leaves the scope, regardless of the return path from the scope. Applicability Whenever a critical section of a method needs to be protected by a locking mechanism. To avoid leaving the method either by a return or because an exception was raised without releasing the lock. A&D 2005 – © François Guibault – e. NGenuity – 2005 30

POSA 2 Patterns Scoped locking Pattern Problem Code that should execute concurrently must be protected by some type of lock that is acquired and released when control enters and leaves a critical section, respectively. If programmers must acquire and release locks explicitly, however, it is hard to ensure that the locks are released in all paths through the code. Solution Define a guard class whose constructor automatically acquires a lock when control enters a scope and whose destructor automatically releases the lock when control leaves the scope. Instantiate instances of the guard class to acquire/release locks in method or block scopes that define critical sections. A&D 2005 – © François Guibault – e. NGenuity – 2005 31

POSA 2 Patterns Scoped locking Pattern Consequences + Increased robustness, - Potential deadlock when used recursively, - Limitations with language-specific semantics. It relies on destructor being called, which is not necessarily true in a thread or process that aborts or exits in a critical section, or in the case of a ‘C’ longjmp(). A&D 2005 – © François Guibault – e. NGenuity – 2005 32

POSA 2 Patterns Strategized locking Pattern Intent To parameterize synchronization mechanisms that protect a component’s critical sections from concurrent access. Applicability When an application or system has components that must run efficiently in a variety of different concurrency architectures. A&D 2005 – © François Guibault – e. NGenuity – 2005 33

POSA 2 Patterns Strategized locking Pattern Problem Components that run in multi-threaded environments must protect their critical sections from concurrent client access. Integrating synchronization mechanisms with component functionality must balance between the need to respect different applications’ needs (mutexes, readers/writers locks, semaphores) with the necessity to avoid code duplication. Solution Parameterize a component’s synchronization aspects by making them pluggable types. Each type represents a particular synchronization strategy. Define instances of these pluggable types as objects contained within a component that can use the objects to synchronize its implementations efficiently. A&D 2005 – © François Guibault – e. NGenuity – 2005 34

POSA 2 Patterns Strategized locking Pattern Consequences + + + - Enhanced flexibility and customization, Decreased maintenance effort for components, Improved reuse, Obstrusive locking, Over-engineering. A&D 2005 – © François Guibault – e. NGenuity – 2005 35

POSA 2 Patterns Thread-safe interface Pattern Intent Minimize locking overhead and ensure that intra-component method calls do not incur ‘self-deadlock’ by trying to reacquire a lock that is held by the component already. Applicability When a component’s critical sections code that must be protected from concurrent access is spread among many methods and many levels of methods that call other intra-component methods or call methods recursively. A&D 2005 – © François Guibault – e. NGenuity – 2005 36

POSA 2 Patterns Thread-safe interface Pattern Problem Multi-threaded components often contain multiple publiclyaccessible interface methods and private implementation methods that can alter the component states. Component methods may call each other to carry out their computations. If this occurs, proper intra-component method invocation must be designed so that : • ‘self-deadlock’ is avoided, and • minimal locking overhead is incurred. A&D 2005 – © François Guibault – e. NGenuity – 2005 37

POSA 2 Patterns Thread-safe interface Pattern Solution Structure all components that process intra-component method invocations according to two design conventions: • Interface methods check, • Implementation methods trust. A&D 2005 – © François Guibault – e. NGenuity – 2005 38

POSA 2 Patterns Thread-safe interface Pattern Consequences + + + - Increased robustness, Enhanced performance, Simplification of software, Additional indirection and extra methods, Potential inter-component deadlock, Potential intra-component deadlock among different objects, Potential overhead. A&D 2005 – © François Guibault – e. NGenuity – 2005 39

POSA 2 Patterns Double-Checked Locking Optimization Pattern Intent Reduce contention and synchronization overhead whenever critical sections of code must acquire locks in a thread-safe manner just once during program execution. Applicability class Singleton { When a component has a critical section of initialization code that must be protected from concurrent access which is executed only once, and when it is not efficient to simply use scoped locking for this code. public: static Singleton* instance () { if( instance == 0 ) { // Enter critical section. instance_ = new Singleton(); // Leave critical section } return instance_; } }; A&D 2005 – © François Guibault – e. NGenuity – 2005 40

POSA 2 Patterns Double-Checked Locking Optimization Pattern Problem Concurrent applications must ensure that certain portions of their code execute serially to avoid race conditions when accessing and modifying shared resources. A common way of protecting critical sections is to use scoped locking, but this may represent unacceptable overhead when the protected code must be executed only once. A&D 2005 – © François Guibault – e. NGenuity – 2005 41

POSA 2 Patterns Double-Checked Locking Optimization Pattern Solution Introduce a flag that provides a ‘hint’ about whether it is necessary to execute a critical section before acquiring the lock that guards it. If this code need not be executed the critical section is skipped, thereby avoiding unnecessary locking overhead. // Perform first-check to evaluate ‘hint’ If (first_time_in_flag is TRUE) { class Singleton { public: static Singleton* instance () { acquire the mutex if( instance == 0 ) { // Perform double-check to avoid race condition // Use Scoped Locking to acquire and If (first_time_in_flag is TRUE) { // release lock automatically. execute critical section Guard<Thread_Mutex> guard( singleton. Lck ); set first_time_in_flag to FALSE // Double check } if( instance_ == 0 ) } instance_ = new Singleton(); } return instance_; } A&D 2005 – © François Guibault – e. NGenuity – 2005 }; 42

POSA 2 Patterns Double-Checked Locking Optimization Pattern Consequences + + - Minimized locking overhead, Prevents race conditions, Non-atomic pointer or integral assignment semantics, Multi-processor cache coherency, Additional mutex usage. A&D 2005 – © François Guibault – e. NGenuity – 2005 43

POSA 2 Patterns Concurrency patterns 1. 2. 3. 4. 5. Active Object Half-Sync/Half-Async Monitor Object Leader/Followers Thread-Specific Storage A&D 2005 – © François Guibault – e. NGenuity – 2005 44

POSA 2 Patterns Active Object Pattern Intent Decouple method execution from method invocation to enhance concurrency and simplify synchronized access to objects that reside in their own threads of control. Applicability When clients access objects running in separate threads of control for enhanced processing performance. When clients should not be tied to specific synchronization, serialization and method scheduling details. A&D 2005 – © François Guibault – e. NGenuity – 2005 45

POSA 2 Patterns Active Object Pattern Structure Client Proxy Scheduler method_1() method_2() Future Activation Queue enqueue() dequeue() Method. Request enqueue() dequeue() Concrete Method. Request 1 Servant method_1() method_2() Concrete Method. Request 2 A&D 2005 – © François Guibault – e. NGenuity – 2005 46

POSA 2 Patterns Active Object Pattern Consequences + Enhances application concurrency and simplifies synchronization complexity, + Transparently leverages available parallelism, + Method execution order can differ from method invocation order, - Performance overhead, - Debugging complexity. A&D 2005 – © François Guibault – e. NGenuity – 2005 47

POSA 2 Patterns Half-Sync/Half-Async Pattern Intent Decouple asynchronous and synchronous service processing in concurrent systems to simplify programming without unduly reducing performance. Applicability When a concurrent system performs both asynchronous and synchronous processing services that must intercommunicate. A&D 2005 – © François Guibault – e. NGenuity – 2005 48

POSA 2 Patterns Half-Sync/Half-Async Pattern Structure Sync Service 1 Sync Service 2 Sync Service 3 Queue Async Service External Event Source A&D 2005 – © François Guibault – e. NGenuity – 2005 49

POSA 2 Patterns Half-Sync/Half-Async Pattern Consequences + + + - Simplification and performance, Separation of concerns, Centralization of inter-layer communication, Possible boundary-crossing penalty, Higher-level applications services may not benefit from the efficiency of asynchronous I/O. A&D 2005 – © François Guibault – e. NGenuity – 2005 50

POSA 2 Patterns Event handling patterns 1. 2. 3. 4. Reactor Proactor Asynchronous Completion Token Acceptor-Connector A&D 2005 – © François Guibault – e. NGenuity – 2005 51