Performance and Scalability Analysis of Java IO and NIO Based Server Models, Their Implementation and Comparison

Total Page:16

File Type:pdf, Size:1020Kb

Performance and Scalability Analysis of Java IO and NIO Based Server Models, Their Implementation and Comparison UKRAINIAN CATHOLIC UNIVERSITY BACHELOR THESIS Performance and scalability analysis of Java IO and NIO based server models, their implementation and comparison Author: Supervisor: Petro KARABYN Oleg FARENYUK A thesis submitted in fulfillment of the requirements for the degree of Bachelor of Science in the Department of Computer Sciences Faculty of Applied Sciences Lviv 2019 ii Declaration of Authorship I, Petro KARABYN, declare that this thesis titled, “Performance and scalability analy- sis of Java IO and NIO based server models, their implementation and comparison” and the work presented in it are my own. I confirm that: • This work was done wholly or mainly while in candidature for a research de- gree at this University. • Where any part of this thesis has previously been submitted for a degree or any other qualification at this University or any other institution, this has been clearly stated. • Where I have consulted the published work of others, this is always clearly attributed. • Where I have quoted from the work of others, the source is always given. With the exception of such quotations, this thesis is entirely my own work. • I have acknowledged all main sources of help. • Where the thesis is based on work done by myself jointly with others, I have made clear exactly what was done by others and what I have contributed my- self. Signed: Date: iii UKRAINIAN CATHOLIC UNIVERSITY Faculty of Applied Sciences Bachelor of Science Performance and scalability analysis of Java IO and NIO based server models, their implementation and comparison by Petro KARABYN Abstract This thesis focuses on the scalability and performance analysis of the web applica- tions built with the IO packages present in the Java programming language. One of the objectives is to compare the thread-oriented and event-driven models and exam- ine the implications of using them in Java IO and NIO-based systems. Three types of concurrency strategies are proposed for dealing with blocking and non-blocking IO and then applied in practice to build a chat engine. Results of the experiments show that in the case of active long-lived connections the difference in throughput between Java IO and NIO is marginal. However, NIO has an edge when it comes to large amounts of simultaneous connections and offers minimal memory consump- tion. iv Acknowledgements I would like to express words of gratitude to my project advisor, Oleg Farenyuk, for guidance throughout my student years. Your professionalism and deep competence in the wide area of subjects have always inspired me to put a lot of effort into learn- ing. Your valuable advice has helped a great deal and directed me in my professional career path. Also, I would like to acknowledge current and past members of the Applied Sciences Faculty and everyone who at some point contributed to the growth and success of the Computer Science program. The work you did will continue to give back to society for the years to come. v Contents Declaration of Authorship ii Abstract iii Acknowledgements iv 1 Introduction1 2 Background4 2.1 Thread-based model.............................5 2.2 Event-driven model..............................7 2.3 Reactor pattern................................9 2.4 The C10K Problem.............................. 11 3 Related works 12 3.1 Duality argument............................... 13 3.1.1 Message-oriented system...................... 13 3.1.2 Procedure-oriented system..................... 14 3.1.3 Differences and a modern look................... 15 3.1.4 Conclusions.............................. 15 3.2 SEDA...................................... 16 3.2.1 High-level overview......................... 16 3.2.2 Types of stages............................ 17 3.2.3 Anatomy of a stage.......................... 18 3.2.4 Conclusions.............................. 19 3.3 Thousands of Threads and Blocking I/O.................. 20 4 Scalable I/O in Java 21 4.1 Java IO and NIO................................ 22 4.1.1 IO streams vs. NIO channels and buffers............. 22 4.1.2 Blocking vs. non-blocking IO.................... 23 4.1.3 Selectors and design implications................. 24 4.1.4 Summary............................... 25 4.2 I/O concurrency strategies.......................... 26 4.2.1 Multithreaded Blocking I/O.................... 26 4.2.2 Single Threaded Non-Blocking I/O................ 27 4.2.3 Multithreaded Non-Blocking I/O................. 29 4.3 I/O trends in enterprise software...................... 30 5 Experiments 32 5.1 Implementation................................ 33 5.2 Test setup.................................... 34 5.3 Real world simulation test.......................... 35 5.3.1 Metrics................................. 36 vi 5.4 High load test................................. 38 5.4.1 Metrics................................. 39 5.5 Analysis.................................... 41 6 Conclusion 44 Bibliography 46 vii List of Figures 2.1 Thread-based server design. This figure illustrates a thread-based model for a server where each incoming client request is processed in a separate thread. The request related computations and internal I/O operations are done by the allocated thread which sends the re- sponse to the client upon completion. This model is also referred to as thread-per-request..............................6 2.2 Event-driven server design. The main thread processes the events from the event queue passing them to the event handler that would execute the associated code. The events can be requests from clients or any other notifications from external systems. Note, that this is a conceptual diagram with a single event handler displayed, in prac- tice, there can be multiple event handlers or one per each type of the expected events.................................8 2.3 Reactor pattern UML............................. 10 3.1 Conceptual illustration of a message-oriented system. Processes have message ports to receive messages in queue and their own data. A process operates data contained by another process by means of ex- plicit message passing mechanism..................... 13 3.2 Conceptual illustration of a procedure-oriented system. Global data is shared across the processes. Monitor encapsulates the data and pro- vides methods for synchronized access. In order to manipulate the global data, a process has to first acquire the mutex. Any other pro- cess can’t change the state of the global data until the mutex is re- leased. This way the shared data is manipulated one process at a time and sychronization is achieved........................ 14 3.3 A high-level overview of the SEDA processing scheme.......... 16 3.4 SEDA types of stages............................. 17 3.5 Anatomy of a SEDA stage. Consists of an incoming queue for the events, an event handler, a dynamically sized thread pool, and a con- troller responsible for scheduling, monitoring the load, and adjusting the parameters at runtime........................... 18 4.1 Stream oriented IO.............................. 23 4.2 Buffer oriented IO............................... 23 4.3 Thread-per connection design schema of standard IO-based application 24 4.4 Design schema of a NIO application with a Selector........... 25 4.5 Multithreaded Blocking I/O......................... 26 4.6 Single Threaded Non-Blocking I/O..................... 28 4.7 Multithreaded Non-Blocking I/O...................... 29 5.1 Test setup.................................... 34 5.2 Chat server latency.............................. 36 viii 5.3 Comparison of chat server latency at 10 000 concurrent clients..... 36 5.4 Chat server CPU utilization......................... 37 5.5 Chat server heap usage............................ 37 5.6 Chat server threads.............................. 38 5.7 Chat server throughput........................... 39 5.8 Chat server outgoing messages....................... 39 5.9 Chat server CPU utilization at high load.................. 40 5.10 Chat server heap usage at high load.................... 40 5.11 Chat server threads at high load....................... 41 ix List of Tables 3.1 Duality mapping................................ 15 3.2 Duality mapping: modern look. Adapted to thread-based and event- driven concepts (Li and Zdancewic, 2007)................. 15 4.1 Differences between Java IO and NIO................... 25 x List of Abbreviations CPU Central processing unit FD File descriptor GUI Graphical user interface IOCP I/O completion ports IO Input/Output JDK Java Development Kit JSR Java Specification Request OS Operating System MOS Message-oriented system POS Procedure-oriented system Req/s Requests per second RAM Random access memory SEDA Staged event-driven architecture TCP Transmission Control Protocol xi Definitions Process an independent active program managed by the operating system that is not sharing the same address space with other programs. Thread a smallest unit of execution that can be managed by a scheduler and may share memory and resources with its peer threads within a process, often re- ferred to as a lightweight process. Message an item of data that is sent to a specific destination. Event a signal emitted by a component upon reaching a given state or any other action detected by a program. Event-driven programming a programming paradigm in which the execution of a program is determined by the events it listens and reacts to. Synchronous execution a mode in which a program is executed line-by-line in a predetermined sequence of tasks, where each subsequent task has to wait be- fore the previous
Recommended publications
  • Next Generation Web Scanning Presentation
    Next generation web scanning New Zealand: A case study First presented at KIWICON III 2009 By Andrew Horton aka urbanadventurer NZ Web Recon Goal: To scan all of New Zealand's web-space to see what's there. Requirements: – Targets – Scanning – Analysis Sounds easy, right? urbanadventurer (Andrew Horton) www.morningstarsecurity.com Targets urbanadventurer (Andrew Horton) www.morningstarsecurity.com Targets What does 'NZ web-space' mean? It could mean: •Geographically within NZ regardless of the TLD •The .nz TLD hosted anywhere •All of the above For this scan it means, IPs geographically within NZ urbanadventurer (Andrew Horton) www.morningstarsecurity.com Finding Targets We need creative methods to find targets urbanadventurer (Andrew Horton) www.morningstarsecurity.com DNS Zone Transfer urbanadventurer (Andrew Horton) www.morningstarsecurity.com Find IP addresses on IRC and by resolving lots of NZ websites 58.*.*.* 60.*.*.* 65.*.*.* 91.*.*.* 110.*.*.* 111.*.*.* 113.*.*.* 114.*.*.* 115.*.*.* 116.*.*.* 117.*.*.* 118.*.*.* 119.*.*.* 120.*.*.* 121.*.*.* 122.*.*.* 123.*.*.* 124.*.*.* 125.*.*.* 130.*.*.* 131.*.*.* 132.*.*.* 138.*.*.* 139.*.*.* 143.*.*.* 144.*.*.* 146.*.*.* 150.*.*.* 153.*.*.* 156.*.*.* 161.*.*.* 162.*.*.* 163.*.*.* 165.*.*.* 166.*.*.* 167.*.*.* 192.*.*.* 198.*.*.* 202.*.*.* 203.*.*.* 210.*.*.* 218.*.*.* 219.*.*.* 222.*.*.* 729,580,500 IPs. More than we want to try. urbanadventurer (Andrew Horton) www.morningstarsecurity.com IP address blocks in the IANA IPv4 Address Space Registry Prefix Designation Date Whois Status [1] -----
    [Show full text]
  • Leader/Followers
    Leader/Followers Douglas C. Schmidt, Carlos O’Ryan, Michael Kircher, Irfan Pyarali, and Frank Buschmann {schmidt, coryan}@uci.edu, {Michael.Kircher, Frank.Buschmann}@mchp.siemens.de, [email protected] University of California at Irvine, Siemens AG, and Washington University in Saint Louis The Leader/Followers architectural pattern provides an efficient concurrency model where multiple threads take turns sharing a set of event sources in order to detect, de- multiplex, dispatch, and process service requests that occur on these event sources. Example Consider the design of a multi-tier, high-volume, on-line transaction processing (OLTP) system. In this design, front-end communication servers route transaction requests from remote clients, such as travel agents, claims processing centers, or point-of-sales terminals, to back-end database servers that process the requests transactionally. After a transaction commits, the database server returns its results to the associated communication server, which then forwards the results back to the originating remote client. This multi-tier architecture is used to improve overall system throughput and reliability via load balancing and redundancy, respectively.It LAN WAN Front-End Back-End Clients Communication Servers Database Servers also relieves back-end servers from the burden of managing different communication protocols with clients. © Douglas C. Schmidt 1998 - 2000, all rights reserved, © Siemens AG 1998 - 2000, all rights reserved 19.06.2000 lf.doc 2 Front-end communication servers are actually ``hybrid'' client/server applications that perform two primary tasks: 1 They receive requests arriving simultaneously from hundreds or thousands of remote clients over wide area communication links, such as X.25 or TCP/IP.
    [Show full text]
  • 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
    [Show full text]
  • A Survey of Architectural Styles.V4
    Survey of Architectural Styles Alexander Bird, Bianca Esguerra, Jack Li Liu, Vergil Marana, Jack Kha Nguyen, Neil Oluwagbeminiyi Okikiolu, Navid Pourmantaz Department of Software Engineering University of Calgary Calgary, Canada Abstract— In software engineering, an architectural style is a and implementation; the capabilities and experience of highest-level description of an accepted solution to a common developers; and the infrastructure and organizational software problem. This paper describes and compares a selection constraints [30]. These styles are not presented as out-of-the- of nine accepted architectural styles selected by the authors and box solutions, but rather a framework within which a specific applicable in various domains. Each pattern is presented in a software design may be made. If one were to say “that cannot general sense and with a domain example, and then evaluated in be called a layered architecture because the such and such a terms of benefits and drawbacks. Then, the styles are compared layer must communicate with an object other than the layer in a condensed table of advantages and disadvantages which is above and below it” then one would have missed the point of useful both as a summary of the architectural styles as well as a architectural styles and design patterns. They are not intended tool for selecting a style to apply to a particular project. The to be definitive and final, but rather suggestive and a starting paper is written to accomplish the following purposes: (1) to give readers a general sense of several architectural styles and when point, not to be used as a rule book but rather a source of and when not to apply them, (2) to facilitate software system inspiration.
    [Show full text]
  • Dspace 1.8 Documentation
    DSpace 1.8 Documentation DSpace 1.8 Documentation Author: The DSpace Developer Team Date: 03 November 2011 URL: https://wiki.duraspace.org/display/DSDOC18 Page 1 of 621 DSpace 1.8 Documentation Table of Contents 1 Preface _____________________________________________________________________________ 13 1.1 Release Notes ____________________________________________________________________ 13 2 Introduction __________________________________________________________________________ 15 3 Functional Overview ___________________________________________________________________ 17 3.1 Data Model ______________________________________________________________________ 17 3.2 Plugin Manager ___________________________________________________________________ 19 3.3 Metadata ________________________________________________________________________ 19 3.4 Packager Plugins _________________________________________________________________ 20 3.5 Crosswalk Plugins _________________________________________________________________ 21 3.6 E-People and Groups ______________________________________________________________ 21 3.6.1 E-Person __________________________________________________________________ 21 3.6.2 Groups ____________________________________________________________________ 22 3.7 Authentication ____________________________________________________________________ 22 3.8 Authorization _____________________________________________________________________ 22 3.9 Ingest Process and Workflow ________________________________________________________ 24
    [Show full text]
  • 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.
    [Show full text]
  • Building Multiplayer Games with Web Sockets #GHC19 About Us
    Leveling Up: Building Multiplayer Games with Web Sockets #GHC19 About Us: #GHC19 Agenda 0. Introduction 1. Simple Chat Application 2. Multiplayer Game 3. Further Applications #GHC19 www.kahoot.com #GHC19 #GHC19 #GHC19 #GHC19 Diagram source: BMC Blog #GHC19 Diagram source: BMC Blog TCP and UDP are the transport level protocols TCP UDP Reliable Unreliable Connection-oriented Connectionless Segment sequencing No sequencing Acknowledge No acknowledgement segments #GHC19 Source: Pluralsight #GHC19 Diagram source: BMC Blog #GHC19 Diagram source: BMC Blog HTTP is used to share information on the application layer #GHC19 Graphic Source: Webnots Alternatives to WebSockets ● Browser Plug-Ins ● Polling ● Long Polling ● Server-Sent Events (SSE) #GHC19 The WebSocket protocol is used for real-time communication RFC-6455 #GHC19 Source: IETF RFC-6455 Some benefits of WebSockets Event driven Reduces network overhead - no need to send full HTTP requests HTTP compatible Co-exists on same port as your web server TLS/SSL compatible Same security as HTTPS #GHC19 WebSocket connection overview #GHC19 Diagram source: PubNub Staff Opening Handshake Client Handshake Server Handshake #GHC19 Source: IETF RFC-6455 Opening Handshake Client Handshake Server Handshake #GHC19 Source: IETF RFC-6455 Opening Handshake Client Handshake Server Handshake #GHC19 Source: IETF RFC-6455 Opening Handshake Client Handshake Server Handshake #GHC19 Source: IETF RFC-6455 Opening Handshake Client Handshake Server Handshake #GHC19 Source: IETF RFC-6455 Data Transfer Base Framing Protocol
    [Show full text]
  • The Need for Hardware/Software Codesign Patterns - a Toolbox for the New Digital Designer
    The need for Hardware/Software CoDesign Patterns - a toolbox for the new Digital Designer By Senior Consultant Carsten Siggaard, Danish Technological Institute May 30. 2008 Abstract Between hardware and software the level of abstraction has always differed a lot, this is not a surprise, hardware is an abstraction for software and the topics which is considered important by either a hardware developer or a software developer are quite different, making the communication between software and hardware developers (or even departments) difficult. In this report the software concept of design patterns is expanded into hardware, and the need for a new kind of design pattern, The Digital Design Pattern, is announced. Copyright © 2008 Danish Technological Institute Page 1 of 20 Contents Contents ............................................................................................................................................... 2 Background .......................................................................................................................................... 4 What is a design pattern ....................................................................................................................... 4 Three Disciplines when using Design Patterns ................................................................................ 5 Pattern Hatching ........................................................................................................................... 6 Pattern Mining.............................................................................................................................
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • Active Object
    Active Object an Object Behavioral Pattern for Concurrent Programming R. Greg Lavender Douglas C. Schmidt [email protected] [email protected] ISODE Consortium Inc. Department of Computer Science Austin, TX Washington University, St. Louis An earlier version of this paper appeared in a chapter in the book ªPattern Languages of Program Design 2º ISBN 0-201-89527-7, edited by John Vlissides, Jim Coplien, and Norm Kerth published by Addison-Wesley, 1996. : Output : Input Handler Handler : Routing Table : Message Abstract Queue This paper describes the Active Object pattern, which decou- 3: enqueue(msg) ples method execution from method invocation in order to : Output 2: find_route(msg) simplify synchronized access to a shared resource by meth- Handler ods invoked in different threads of control. The Active Object : Message : Input pattern allows one or more independent threads of execution Queue Handler 1: recv(msg) to interleave their access to data modeled as a single ob- ject. A broad class of producer/consumer and reader/writer OUTGOING OUTGOING MESSAGES GATEWAY problems are well-suited to this model of concurrency. This MESSAGES pattern is commonly used in distributed systems requiring INCOMING INCOMING multi-threaded servers. In addition,client applications (such MESSAGES MESSAGES as windowing systems and network browsers), are increas- DST DST ingly employing active objects to simplify concurrent, asyn- SRC SRC chronous network operations. 1 Intent Figure 1: Connection-Oriented Gateway The Active Object pattern decouples method execution from method invocation in order to simplify synchronized access to a shared resource by methods invoked in different threads [2]. Sources and destinationscommunicate with the Gateway of control.
    [Show full text]
  • 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.
    [Show full text]