DOCSLIB.ORG

Object-Oriented Design Patterns for Network Programming in C++ Douglas C. Schmidt Washington University, St. Louis Http

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

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
Recommended publications
  • Design Patterns Promote Reuse

    Design Patterns Promote Reuse

    Design Patterns Promote Reuse “A pattern describes a problem that occurs often, along with a tried solution to the problem” - Christopher Alexander, 1977 • Christopher Alexander’s 253 (civil) architectural patterns range from the creation of cities (2. distribution of towns) to particular building problems (232. roof cap) • A pattern language is an organized way of tackling an architectural problem using patterns Kinds of Patterns in Software • Architectural (“macroscale”) patterns • Model-view-controller • Pipe & Filter (e.g. compiler, Unix pipeline) • Event-based (e.g. interactive game) • Layering (e.g. SaaS technology stack) • Computation patterns • Fast Fourier transform • Structured & unstructured grids • Dense linear algebra • Sparse linear algebra • GoF (Gang of Four) Patterns: structural, creational, behavior The Gang of Four (GoF) • 23 structural design patterns • description of communicating objects & classes • captures common (and successful) solution to a category of related problem instances • can be customized to solve a specific (new) problem in that category • Pattern ≠ • individual classes or libraries (list, hash, ...) • full design—more like a blueprint for a design The GoF Pattern Zoo 1. Factory 13. Observer 14. Mediator 2. Abstract factory 15. Chain of responsibility 3. Builder Creation 16. Command 4. Prototype 17. Interpreter 18. Iterator 5. Singleton/Null obj 19. Memento (memoization) 6. Adapter Behavioral 20. State 21. Strategy 7. Composite 22. Template 8. Proxy 23. Visitor Structural 9. Bridge 10. Flyweight 11.
  • Thread Management for High Performance Database Systems - Design and Implementation

    Thread Management for High Performance Database Systems - Design and Implementation

    Nr.: FIN-003-2018 Thread Management for High Performance Database Systems - Design and Implementation Robert Jendersie, Johannes Wuensche, Johann Wagner, Marten Wallewein-Eising, Marcus Pinnecke, Gunter Saake Arbeitsgruppe Database and Software Engineering Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Nr.: FIN-003-2018 Thread Management for High Performance Database Systems - Design and Implementation Robert Jendersie, Johannes Wuensche, Johann Wagner, Marten Wallewein-Eising, Marcus Pinnecke, Gunter Saake Arbeitsgruppe Database and Software Engineering Technical report (Internet) Elektronische Zeitschriftenreihe der Fakultät für Informatik der Otto-von-Guericke-Universität Magdeburg ISSN 1869-5078 Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Impressum (§ 5 TMG) Herausgeber: Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Der Dekan Verantwortlich für diese Ausgabe: Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Marcus Pinnecke Postfach 4120 39016 Magdeburg E-Mail: [email protected] http://www.cs.uni-magdeburg.de/Technical_reports.html Technical report (Internet) ISSN 1869-5078 Redaktionsschluss: 21.08.2018 Bezug: Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Dekanat Thread Management for High Performance Database Systems - Design and Implementation Technical Report Robert Jendersie1, Johannes Wuensche2, Johann Wagner1, Marten Wallewein-Eising2, Marcus Pinnecke1, and Gunter Saake1 Database and Software Engineering Group, Otto-von-Guericke University
  • Dependency Injection in Unity3d

    Dependency Injection in Unity3d

    Dependency Injection in Unity3D Niko Parviainen Bachelor’s thesis March 2017 Technology, communication and transport Degree Programme in Software Engineering Description Author(s) Type of publication Date Parviainen, Niko Bachelor’s thesis March 2017 Language of publication: English Number of pages Permission for web publi- 57 cation: x Title of publication Dependency Injection in Unity3D Degree programme Degree Programme in Software Engineering Supervisor(s) Rantala, Ari Hämäläinen, Raija Assigned by Psyon Games Oy Abstract The objective was to find out how software design patterns and principles are applied to game development to achieve modular design. The tasks of the research were to identify the dependency management problem of a modular design, find out what the solutions offered by Unity3D are, find out what the dependency injection pattern is and how it is used in Unity3D environment. Dependency management in Unity3D and the dependency injection pattern were studied. Problems created by Unity3D’s solutions were introduced with examples. Dependency in- jection pattern was introduced with examples and demonstrated by implementing an ex- ample game using one of the available third-party frameworks. The aim of the example game was to clarify if the use of dependency injection brings modularity in Unity3D envi- ronment and what the cost of using it is. The principles of SOLID were introduced with generic examples and used to assist depend- ency injection to further increase the modularity by bringing the focus on class design. Dependency injection with the help of SOLID principles increased the modularity by loosely coupling classes even though slightly increasing the overall complexity of the architecture.
  • Facet: a Pattern for Dynamic Interfaces

    Facet: a Pattern for Dynamic Interfaces

    Facet: A pattern for dynamic interfaces Author: Eric Crahen SUNY at Buffalo CSE Department Amherst, NY 14260 201 Bell Hall 716-645-3180 <[email protected]> Context: Wherever it is desirable to create a context sensitive interface in order to modify or control the apparent behavior if an object. Problem: How can I modify the behavior of an existing object so that different behaviors are shown under different circumstances; and yet still maintain a clean separation between the policy (when each behavior is available) and implementation of each behavior allowing them to be developed independently of one another? Forces: Interfaces provide an essential level of abstraction to object oriented programming. Generally, objects are able define aspects of their function very well using interfaces. At times, this may not be enough. When dealing with two or more classes whose responsibilities are distinctly separate, but whose behavior is closely related, classes can begin to resist modularization. For example, adding security to an application means inserting code that performs security checks into numerous locations in existing classes. Clearly, these responsibilities are distinct; the original classes being responsible for the tasks they were designed to perform, and the security classes being responsible for providing access control. However, making those original classes secure means intermingling code that deals with security. When the classes dealing with security are changed many classes are going to be impacted. One method of adding new behavior to an existing class might be to simply create a subclass and embed that new behavior. In the security example, this would mean creating a subclass for each class that needs to be secure and adding calls to the security code.
  • Concurrency & Parallel Programming Patterns

    Concurrency & Parallel Programming Patterns

    Concurrency & Parallel programming patterns Evgeny Gavrin Outline 1. Concurrency vs Parallelism 2. Patterns by groups 3. Detailed overview of parallel patterns 4. Summary 5. Proposal for language Concurrency vs Parallelism ● Parallelism is the simultaneous execution of computations “doing lots of things at once” ● Concurrency is the composition of independently execution processes “dealing with lots of thing at once” Patterns by groups Architectural Patterns These patterns define the overall architecture for a program: ● Pipe-and-filter: view the program as filters (pipeline stages) connected by pipes (channels). Data flows through the filters to take input and transform into output. ● Agent and Repository: a collection of autonomous agents update state managed on their behalf in a central repository. ● Process control: the program is structured analogously to a process control pipeline with monitors and actuators moderating feedback loops and a pipeline of processing stages. ● Event based implicit invocation: The program is a collection of agents that post events they watch for and issue events for other agents. The architecture enforces a high level abstraction so invocation of an agent is implicit; i.e. not hardwired to a specific controlling agent. ● Model-view-controller: An architecture with a central model for the state of the program, a controller that manages the state and one or more agents that export views of the model appropriate to different uses of the model. ● Bulk Iterative (AKA bulk synchronous): A program that proceeds iteratively … update state, check against a termination condition, complete coordination, and proceed to the next iteration. ● Map reduce: the program is represented in terms of two classes of functions.
  • Dependency Injection with Unity

    Dependency Injection with Unity

    D EPEN DEPENDENCY INJECTION WITH UNITY Over the years software systems have evolutionarily become more and more patterns & practices D ENCY complex. One of the techniques for dealing with this inherent complexity Proven practices for predictable results of software systems is dependency injection – a design pattern that I allows the removal of hard-coded dependencies and makes it possible to Save time and reduce risk on your NJECT assemble a service by changing dependencies easily, whether at run-time software development projects by or compile-time. It promotes code reuse and loosely-coupled design which incorporating patterns & practices, I leads to more easily maintainable and flexible code. Microsoft’s applied engineering ON guidance that includes both production The guide you are holding in your hands is a primer on using dependency quality source code and documentation. W I injection with Unity – a lightweight extensible dependency injection TH DEPENDENCY INJECTION container built by the Microsoft patterns & practices team. It covers The guidance is designed to help U software development teams: various styles of dependency injection and also additional capabilities N I of Unity container, such as object lifetime management, interception, Make critical design and technology TY and registration by convention. It also discusses the advanced topics of selection decisions by highlighting WITH UNITY enhancing Unity with your custom extensions. the appropriate solution architectures, technologies, and Microsoft products The guide contains plenty of trade-off discussions and tips and tricks for for common scenarios managing your application cross-cutting concerns and making the most out of both dependency injection and Unity. These are accompanied by a Understand the most important Dominic Betts real world example that will help you master the techniques.
  • Model Checking Multithreaded Programs With

    Model Checking Multithreaded Programs With

    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Illinois Digital Environment for Access to Learning and Scholarship Repository Model Checking Multithreaded Programs with Asynchronous Atomic Methods Koushik Sen and Mahesh Viswanathan Department of Computer Science, University of Illinois at Urbana-Champaign. {ksen,vmahesh}@uiuc.edu Abstract. In order to make multithreaded programming manageable, program- mers often follow a design principle where they break the problem into tasks which are then solved asynchronously and concurrently on different threads. This paper investigates the problem of model checking programs that follow this id- iom. We present a programming language SPL that encapsulates this design pat- tern. SPL extends simplified form of sequential Java to which we add the ca- pability of making asynchronous method invocations in addition to the standard synchronous method calls and the ability to execute asynchronous methods in threads atomically and concurrently. Our main result shows that the control state reachability problem for finite SPL programs is decidable. Therefore, such mul- tithreaded programs can be model checked using the counter-example guided abstraction-refinement framework. 1 Introduction Multithreaded programming is often used in software as it leads to reduced latency, improved response times of interactive applications, and more optimal use of process- ing power. Multithreaded programming also allows an application to progress even if one thread is blocked for an I/O operation. However, writing correct programs that use multiple threads is notoriously difficult, especially in the presence of a shared muta- ble memory. Since threads can interleave, there can be unintended interference through concurrent access of shared data and result in software errors due to data race and atom- icity violations.
  • Lecture 26: Creational Patterns

    Lecture 26: Creational Patterns

    Creational Patterns CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 26 — 11/29/2012 © Kenneth M. Anderson, 2012 1 Goals of the Lecture • Cover material from Chapters 20-22 of the Textbook • Lessons from Design Patterns: Factories • Singleton Pattern • Object Pool Pattern • Also discuss • Builder Pattern • Lazy Instantiation © Kenneth M. Anderson, 2012 2 Pattern Classification • The Gang of Four classified patterns in three ways • The behavioral patterns are used to manage variation in behaviors (think Strategy pattern) • The structural patterns are useful to integrate existing code into new object-oriented designs (think Bridge) • The creational patterns are used to create objects • Abstract Factory, Builder, Factory Method, Prototype & Singleton © Kenneth M. Anderson, 2012 3 Factories & Their Role in OO Design • It is important to manage the creation of objects • Code that mixes object creation with the use of objects can become quickly non-cohesive • A system may have to deal with a variety of different contexts • with each context requiring a different set of objects • In design patterns, the context determines which concrete implementations need to be present © Kenneth M. Anderson, 2012 4 Factories & Their Role in OO Design • The code to determine the current context, and thus which objects to instantiate, can become complex • with many different conditional statements • If you mix this type of code with the use of the instantiated objects, your code becomes cluttered • often the use scenarios can happen in a few lines of code • if combined with creational code, the operational code gets buried behind the creational code © Kenneth M. Anderson, 2012 5 Factories provide Cohesion • The use of factories can address these issues • The conditional code can be hidden within them • pass in the parameters associated with the current context • and get back the objects you need for the situation • Then use those objects to get your work done • Factories concern themselves just with creation, letting your code focus on other things © Kenneth M.
  • Design Patterns in Ocaml

    Design Patterns in Ocaml

    Design Patterns in OCaml Antonio Vicente [email protected] Earl Wagner [email protected] Abstract The GOF Design Patterns book is an important piece of any professional programmer's library. These patterns are generally considered to be an indication of good design and development practices. By giving an implementation of these patterns in OCaml we expected to better understand the importance of OCaml's advanced language features and provide other developers with an implementation of these familiar concepts in order to reduce the effort required to learn this language. As in the case of Smalltalk and Scheme+GLOS, OCaml's higher order features allows for simple elegant implementation of some of the patterns while others were much harder due to the OCaml's restrictive type system. 1 Contents 1 Background and Motivation 3 2 Results and Evaluation 3 3 Lessons Learned and Conclusions 4 4 Creational Patterns 5 4.1 Abstract Factory . 5 4.2 Builder . 6 4.3 Factory Method . 6 4.4 Prototype . 7 4.5 Singleton . 8 5 Structural Patterns 8 5.1 Adapter . 8 5.2 Bridge . 8 5.3 Composite . 8 5.4 Decorator . 9 5.5 Facade . 10 5.6 Flyweight . 10 5.7 Proxy . 10 6 Behavior Patterns 11 6.1 Chain of Responsibility . 11 6.2 Command . 12 6.3 Interpreter . 13 6.4 Iterator . 13 6.5 Mediator . 13 6.6 Memento . 13 6.7 Observer . 13 6.8 State . 14 6.9 Strategy . 15 6.10 Template Method . 15 6.11 Visitor . 15 7 References 18 2 1 Background and Motivation Throughout this course we have seen many examples of methodologies and tools that can be used to reduce the burden of working in a software project.
  • HEDGEHOG: Automatic Verification of Design Patterns in Java

    HEDGEHOG: Automatic Verification of Design Patterns in Java

    HEDGEHOG: Automatic Verification of Design Patterns in Java Alex Blewitt I V N E R U S E I T H Y T O H F G E R D I N B U Doctor of Philosophy School of Informatics University of Edinburgh 2006 Abstract Design patterns are widely used by designers and developers for building complex systems in object-oriented programming languages such as Java. However, systems evolve over time, increasing the chance that the pattern in its original form will be broken. To verify that a design pattern has not been broken involves specifying the original intent of the design pattern. Whilst informal descriptions of patterns exist, no formal specifications are available due to differences in implementations between programming languages. This thesis shows that many patterns (implemented in Java) can be verified automatically. Patterns are defined in terms of variants, mini-patterns, and artefacts in a pattern description language called SPINE. These specifications are then processed by HEDGEHOG, an automated proof tool that attempts to prove that Java source code meets these specifications. iii Acknowledgements I am indebted to Alan Bundy who has given me the freedom to work on this thesis whilst at the same time guiding me towards the final production and presentation of these results. I not would have been able to achieve this without Alan’s support through a sometimes difficult, but always busy part of my life. This project, and especially the production of this thesis, would not have been possible without the care and attention that Alan provided. Ian Stark has provided invaluable feedback on all aspects of this thesis, from the low-level technical intricacies of Java’s design patterns through to the high-level structure of the thesis as a whole.
  • An Enhanced Thread Synchronization Mechanism for Java

    An Enhanced Thread Synchronization Mechanism for Java

    SOFTWARE—PRACTICE AND EXPERIENCE Softw. Pract. Exper. 2001; 31:667–695 (DOI: 10.1002/spe.383) An enhanced thread synchronization mechanism for Java Hsin-Ta Chiao and Shyan-Ming Yuan∗,† Department of Computer and Information Science, National Chiao Tung University, 1001 Ta Hsueh Road, Hsinchu 300, Taiwan SUMMARY The thread synchronization mechanism of Java is derived from Hoare’s monitor concept. In the authors’ view, however, it is over simplified and suffers the following four drawbacks. First, it belongs to a category of no-priority monitor, the design of which, as reported in the literature on concurrent programming, is not well rated. Second, it offers only one condition queue. Where more than one long-term synchronization event is required, this restriction both degrades performance and further complicates the ordering problems that a no-priority monitor presents. Third, it lacks the support for building more elaborate scheduling programs. Fourth, during nested monitor invocations, deadlock may occur. In this paper, we first analyze these drawbacks in depth before proceeding to present our own proposal, which is a new monitor-based thread synchronization mechanism that we term EMonitor. This mechanism is implemented solely by Java, thus avoiding the need for any modification to the underlying Java Virtual Machine. A preprocessor is employed to translate the EMonitor syntax into the pure Java codes that invoke the EMonitor class libraries. We conclude with a comparison of the performance of the two monitors and allow the experimental results to demonstrate that, in most cases, replacing the Java version with the EMonitor version for developing concurrent Java objects is perfectly feasible.
  • Designing for Performance: Concurrency and Parallelism COS 518: Computer Systems Fall 2015

    Designing for Performance: Concurrency and Parallelism COS 518: Computer Systems Fall 2015

    Designing for Performance: Concurrency and Parallelism COS 518: Computer Systems Fall 2015 Logan Stafman Adapted from slides by Mike Freedman 2 Definitions • Concurrency: – Execution of two or more tasks overlap in time. • Parallelism: – Execution of two or more tasks occurs simultaneous. Concurrency without 3 parallelism? • Parts of tasks interact with other subsystem – Network I/O, Disk I/O, GPU, ... • Other task can be scheduled while first waits on subsystem’s response Concurrency without parrallelism? Source: bjoor.me 5 Scheduling for fairness • On time-sharing system also want to schedule between tasks, even if one not blocking – Otherwise, certain tasks can keep processing – Leads to starvation of other tasks • Preemptive scheduling – Interrupt processing of tasks to process another task (why with tasks and not network packets?) • Many scheduling disciplines – FIFO, Shortest Remaining Time, Strict Priority, Round-Robin Preemptive Scheduling Source: embeddedlinux.org.cn Concurrency with 7 parallelism • Execute code concurrently across CPUs – Clusters – Cores • CPU parallelism different from distributed systems as ready availability to shared memory – Yet to avoid difference between parallelism b/w local and remote cores, many apps just use message passing between both (like HPC’s use of MPI) Symmetric Multiprocessors 8 (SMPs) Non-Uniform Memory Architectures 9 (NUMA) 10 Pros/Cons of NUMA • Pros Applications split between different processors can share memory close to hardware Reduced bus bandwidth usage • Cons Must ensure applications sharing memory are run on processors sharing memory 11 Forms of task parallelism • Processes – Isolated process address space – Higher overhead between switching processes • Threads – Concurrency within process – Shared address space – Three forms • Kernel threads (1:1) : Kernel support, can leverage hardware parallelism • User threads (N:1): Thread library in system runtime, fastest context switching, but cannot benefit from multi- threaded/proc hardware • Hybrid (M:N): Schedule M user threads on N kernel threads.