O\'Reilly - Java Threads 2nd Edition

SAVE OFFLINE

Java Threads, 2nd edition Scott Oaks & Henry Wong 2nd Edition January 1999 ISBN: 1-56592-418-5, 332 pages

Revised and expanded to cover Java 2, Java Threads shows you how to take full advantage of Java's thread facilities: where to use threads to increase efficiency, how to use them effectively, and how to avoid common mistakes. It thoroughly covers the Thread and ThreadGroup classes, the Runnable interface, and the language's synchronized operator. The book pays special attention to threading issues with Swing, as well as problems like deadlock, race condition, and starvation to help you write code without hidden bugs.

Table of Contents Preface

1

1. Introduction to Threading Java Terms Thread Overview Why Threads? Summary

5

2. The Java Threading API Threading Using the Thread Class Threading Using the Runnable Interface The Life Cycle of a Thread Thread Naming Thread Access More on Starting, Stopping, and Joining Summary

12

3. Synchronization Techniques A Banking Example Reading Data Asynchronously A Class to Perform Synchronization The Synchronized Block Nested Locks Deadlock Return to the Banking Example Synchronizing Static Methods Summary

31

4. Wait and Notify Back to Work (at the Bank) Wait and Notify wait(), notify(), and notifyAll() wait() and sleep() Thread Interruption Static Methods (Synchronization Details) Summary

50

5. Useful Examples of Java Thread Programming Data Structures and Containers Simple Synchronization Examples A Network Server Class The AsyncInputStream Class Using TCPServer with AsyncInputStreams Summary

64

6. Java Thread Scheduling An Overview of Thread Scheduling When Scheduling Is Important Scheduling with Thread Priorities Popular Scheduling Implementations Native Scheduling Support Other Thread-Scheduling Methods Summary

87

Table of Contents (cont...) 7. Java Thread Scheduling Examples Thread Pools Round-Robin Scheduling Job Scheduling Summary

117

8. Advanced Synchronization Topics Synchronization Terms Preventing Deadlock Lock Starvation Thread-Unsafe Classes Summary

137

9. Parallelizing for Multiprocessor Machines Parallelizing a Single-Threaded Program Inner-Loop Threading Loop Printing Multiprocessor Scaling Summary

162

10. Thread Groups Thread Group Concepts Creating Thread Groups Thread Group Methods Manipulating Thread Groups Thread Groups, Threads, and Security Summary

189

A. Miscellaneous Topics

203

B. Exceptions and Errors

209

Colophon

214

Description Threads aren't a new idea: many operating systems and languages support them. But despite widespread support, threads tend to be something that everyone talks about, but few use. Programming with threads has a reputation for being tricky and nonportable. Not so with Java. Java's thread facilities are easy to use, and - like everything else in Java - are completely portable between platforms. And that's a good thing, because it's impossible to write anything but the simplest applet without encountering threads. If you want to work with Java, you have to learn about threads. This new edition shows you how to take full advantage of Java's thread facilities: where to use threads to increase efficiency, how to use them effectively, and how to avoid common mistakes. Java Threads discusses problems like deadlock, race condition, and starvation in detail, helping you to write code without hidden bugs. It brings you up to date with the latest changes in the thread interface for JDK 1.2. The book offers a thorough discussion of the Thread and ThreadGroup classes, the Runnable interface, the language's synchronized operator. It explains thread scheduling ends by developing a CPUSchedule class, showing you how to implement your own scheduling policy. In addition, Java Threads shows you how to extend Java's thread primitives. Other extended examples include classes that implement reader/writer locks, general locks, locks at arbitrary scope, and asynchronous I/O. This edition also adds extensive examples on thread pools, advanced synchronization technique, like condition variables, barriers, and daemon locks. It shows how to work with classes that are not thread safe, and pays special attention to threading issues with Swing. A new chapter shows you how to write parallel code for multiprocessor machines. In short, Java Threads covers everything you need to know about threads, from the simplest animation applet to the most complex applications. If you plan to do any serious work in Java, you will find this book invaluable. Examples available online. Covers Java 2.

Java Threads, 2nd edition

Preface When Sun Microsystems released the first alpha version of Java™ in the winter of 1995, developers all over the world took notice. There were many features of Java that attracted these developers, not the least of which were the set of buzzwords Sun used to promote Java: Java was, among other things, robust, safe, architecture-neutral, portable, object oriented, simple, and multithreaded. For many developers, these last two buzzwords seemed contradictory: how could a language that is multithreaded be simple? It turns out that Java's threading system is simple, at least relative to other threading systems. This simplicity makes Java's threading system easy to learn, so that even developers who are unfamiliar with threads can pick up the basics of thread programming with relative ease. But this simplicity comes with trade-offs: some of the advanced features that are found in other threading systems are not present in Java. However, these features can be built by the Java developer from the simpler constructs Java provides. And that's the underlying theme of this book: how to use the threading tools in Java to perform the basic tasks of threaded programming, and how to extend them to perform more advanced tasks for more complex programs.

Who Should Read This Book? This book is intended for programmers of all levels who need to learn to use threads within Java programs. The first few chapters of the book deal with the issues of threaded programming in Java, starting at a basic level: no assumption is made that the developer has had any experience in threaded programming. As the chapters progress, the material becomes more advanced, in terms of both the information presented and the experience of the developer that the material assumes. For developers who are new to threaded programming, this sequence should provide a natural progression of the topic. This progression mimics the development of Java itself as well as the development of books about Java. Early Java programs tended to be simple, though effective: an animated image of Duke dancing on a web page was a powerful advertisement of Java's potential, but it barely scratched the surface of that potential. Similarly, early books about Java tended to be complete overviews of Java with only a chapter or two dedicated to Java's threading system. This book belongs to the second wave of Java books: because it covers only a single topic, it has the luxury of explaining in deeper detail how Java's threads can be used. It's ideally suited to developers targeting the second wave of Java programs - more complex programs that fully exploit the power of Java's threading system. Though the material presented in this book does not assume any prior knowledge of threads, it does assume that the reader has a knowledge of other areas of the Java API and can write simple Java programs.

Versions Used in This Book Writing a book on Java in the age of Internet time is hard: the sand on which we're standing is constantly shifting. But we've drawn a line in that sand, and the line we've drawn is at the JDK™ 2 from Sun Microsystems. It's likely that versions of Java that postdate Java 2 will contain some changes to the threading system not discussed in this version of the book. We will also point out the differences between Java 2 and previous versions of Java as we go, so that developers who are using earlier releases of Java will also be able to use this book. Some vendors that provide Java - either embedded in browsers or as a development system - are contemplating releasing extensions to Java that provide additional functionality to Java's threading system (in much the same way as the examples we provide in Chapter 5 through Chapter 8 use the basic techniques of the Java threaded system to provide additional functionality). Those extensions are beyond the scope of this book: we're concerned only with the reference JDK 2 from Sun Microsystems. The only time we'll consider platform differences is in reference to an area of the reference JDK that differs on Unix platforms and Windows platforms: these platforms contain some differences in the scheduling of Java threads, a topic we'll address in Chapter 6.

page 1

Java Threads, 2nd edition

Organization of This Book Here's an outline of the book, showing the progression of the material we present. The material in the appendixes is generally either too immature to present fully or is mostly of academic interest, although it may be useful in rare cases. Chapter 1 This chapter introduces the concept of threads and the terms we use in the book. Chapter 2 This chapter introduces the Java API that allows the programmer to create threads. Chapter 3 This chapter introduces the simple locking mechanism that Java developers can use to synchronize access to data and code. Chapter 4 This chapter introduces the other Java mechanism that developers use to synchronize access to data and code. Chapter 5 This chapter summarizes the techniques presented in the previous chapters. Unlike the earlier chapters, this chapter is solutions oriented: the examples give you an idea of how to put together the basic threading techniques that have been presented so far, and provide some insight into designing effectively using threads. Chapter 6 This chapter introduces the Java API that controls how threads are scheduled by the virtual machine, including a discussion of scheduling differences between different implementations of the virtual machine. Chapter 7 This chapter provides examples that extend Java's scheduling model, including techniques to provide round-robin scheduling and thread pooling. Chapter 8 This chapter discusses various advanced topics related to data synchronization, including designing around deadlock and developing some additional synchronization classes, including synchronization methods from other platforms that are not directly available in Java. Chapter 9 This chapter discusses how to design your program to take advantage of a machine with multiple processors. Chapter 10 This chapter discusses Java's ThreadGroup class, which allows a developer to control and manipulate groups of threads. Java's security mechanism for threads is based on this class and is also discussed in this chapter. Appendix A This appendix presents a few methods of the Java API that are of limited interest: methods that deal with the thread's stack and the ThreadDeath class. Appendix B This appendix presents the details of the exceptions and errors that are used by the threading system.

page 2

Java Threads, 2nd edition

Conventions Used in This Book Constant width font is used for:

•

Code examples: public void main(String args[]) { System.out.println("Hello, world"); }

•

Method, variable, and parameter names within the text, as well as keywords

Bold constant width font is used for:

•

Presenting revised code examples as we work through a problem: public void main(String args[]) { System.out.println("Hello, world"); }

•

Highlighting a section of code for discussion within a longer code example

Italic font is used for URLs and filenames, and to introduce new terms. Examples of the programs in this book may be retrieved online from: http://www.oreilly.com/catalog/jthreads2

Feedback for Authors We've attempted to be complete and accurate throughout this book. Changes in releases of the Java specification as well as differing vendor implementations across many platforms and underlying operating systems make it impossible to be completely accurate in all cases (not to mention the possibility of our having made a mistake somewhere along the line). This book is a work in progress, and as Java continues to evolve, so, too, will this book. Please let us know about any errors you find, as well as your suggestions for future editions, by writing to: O'Reilly & Associates, Inc. 101 Morris Street Sebastopol, CA 95472 1-800-998-9938 (in the U.S. or Canada) 1-707-829-0515 (international/local) 1-707-829-0104 (FAX) You can also send us messages electronically. To be put on the mailing list or request a catalog, send email to: http://safari2.oreilly.com/[email protected] To ask technical questions or comment on the book, send email to: [email protected] We have a web site for the book, where we'll list examples, errata, and any plans for future editions. You can access this page at: http://www.oreilly.com/catalog/jthreads2/ For more information about this book and others, see the O'Reilly web site: http://www.oreilly.com/ The authors welcome your feedback about this book, especially if you spot errors or omissions that we have made. You can contact us at [email protected] and [email protected].

page 3

Java Threads, 2nd edition

Acknowledgments As readers of prefaces are well aware, writing a book is never an effort undertaken solely by the authors who get all the credit on the cover. We are deeply indebted to the following people for their help and encouragement: Michael Loukides, who believed us when we said that this was an important topic and who shepherded us through the creative process; David Flanagan, for valuable feedback on the drafts; Hong Zhang, for helping us with Windows threading issues; and Reynold Jabbour and Wendy Talmont, for supporting us in our work. Mostly, we must thank our respective families. To James, who gave Scott the support and encouragement necessary to see this book through (and to cope with his continual state of distraction), and to Nini, who knew to leave Henry alone for the ten percent of the time when he was creative, and encouraged him the rest of the time: Thank you for everything! Finally, we must thank the many readers of the first edition of this book who sent us invaluable feedback. We have tried our best to answer every concern that they have raised. Keep those cards and letters coming!

page 4

Java Threads, 2nd edition

Chapter 1. Introduction to Threading This is a book about using threads in the Java programming language and the Java virtual machine. The topic of threads is very important in Java - so important that many features of a threaded system are built into the Java language itself, while other features of a threaded system are required by the Java virtual machine. Threading is an integral part of using Java. The concept of threads is not a new one: for some time, many operating systems have had libraries that provide the C programmer with a mechanism to create threads. Other languages, such as Ada, have support for threads embedded into the language, much as support for threads is built into the Java language. Nonetheless, the topic of threads is usually considered a peripheral programming topic, one that's only needed in special programming cases. With Java, things are different: it is impossible to write any but the simplest Java program without introducing the topic of threads. And the popularity of Java ensures that many developers who might never have considered learning about threading possibilities in a language like C or C++ need to become fluent in threaded programming.

1.1 Java Terms We'll start by defining some terms used throughout this book. Many terms surrounding Java are used inconsistently in various sources; we'll endeavor to be consistent in our usage of these terms throughout the book. Java First is the term Java itself. As we know, Java started out as a programming language, and many people today think of Java as being simply a programming language. But Java is much more than just a programming language: it's also an API specification and a virtual machine specification. So when we say Java, we mean the entire Java platform: a programming language, an API, and a virtual machine specification that, taken together, define an entire programming and runtime environment. Often when we say Java, it's clear from context that we're talking specifically about the programming language, or parts of the Java API, or the virtual machine. The point to remember is that the threading features we discuss in this book derive their properties from all the components of the Java platform taken as a whole. While it's possible to take the Java programming language, directly compile it into assembly code, and run it outside of the virtual machine, such an executable may not necessarily behave the same as the programs we describe in this book. Virtual machine, interpreters, and browsers The Java virtual machine is another term for the Java interpreter, which is the code that ultimately runs Java programs by interpreting the intermediate byte-code format of the Java programming language. The Java interpreter actually comes in three popular forms: the interpreter for developers (called java) that runs programs via the command line or a file manager, the interpreter for end users (called jre ) that is a subset of the developer environment and forms the basis of (among other things) the Java plug-in, and the interpreter that is built into many popular web browsers such as Netscape Navigator, Internet Explorer, HotJava™, and the appletviewer that comes with the Java Developer's Kit. All of these forms are simply implementations of the Java virtual machine, and we'll refer to the Java virtual machine when our discussion applies to any of them. When we use the term Java interpreter, we're talking specifically about the command-line, standalone version of the virtual machine (including those virtual machines that perform just-in-time compilation); when we use the term Java-enabled browser (or, more simply, browser), we're talking specifically about the virtual machine built into web browsers. For the most part, virtual machines are indistinguishable - at least in theory. In practice, there are a few important differences between implementations of virtual machines, and one of those differences comes in the world of threads. This difference is important in relatively few circumstances, and we'll discuss it in Chapter 6.

page 5

Java Threads, 2nd edition

Programs, applications, and applets This leads us to the terms that we'll use for things written in the Java language. Generically, we'll call such entities programs. But there are two types of programs a typical Java programmer might write: programs that can be run directly by the Java interpreter and programs designed to be run by a Java-enabled browser.[1] Much of the time, the distinction between these two types of Java programs is not important, and in those cases, we'll refer to them as programs. But in those cases where the distinction is important, we'll use the term applets for programs running in the Java-enabled browser and the term applications for standalone Java programs. In terms of threads, the distinction between an applet and an application manifests itself only in Java's security model; we'll discuss the interaction between the security model and Java threads in Chapter 10. Though it's possible to write a single Java program so that it can be run both by the interpreter and by a browser, the distinction still applies at the time the program is actually run.

[1]

1.2 Thread Overview This leaves us only one more term to define: what exactly is a thread? The term thread is shorthand for thread of control, and a thread of control is, at its simplest, a section of code executed independently of other threads of control within a single program.

Thread of Control Thread of control sounds like a complicated technical term, but it's really a simple concept: it is the path taken by a program during execution. This determines what code will be executed: does the if block get executed, or does the else block? How many times does the while loop execute? If we were executing tasks from a "to do" list, much as a computer executes an application, what steps we perform and the order in which we perform them is our path of execution, the result of our thread of control. Having multiple threads of control is like executing tasks from two lists. We are still doing the tasks on each "to do" list in the correct order, but when we get bored with the tasks on one of the lists, we switch lists with the intention of returning at some future time to the first list at the exact point where we left off.

1.2.1 Overview of Multitasking We're all familiar with the use of multitasking operating systems to run multiple programs simultaneously. Each of these programs has at least one thread within it, so at some level, we're already comfortable with the notion of a thread in a single process. The single-threaded process has the following properties, which, as it turns out, are shared by all threads in a program with multiple threads as well: •

The process begins execution at a well-known point. In programming languages like C and C++ (not to mention Java itself), the thread begins execution at the first statement of the function or method called main() .

•

Execution of the statements follows in a completely ordered, predefined sequence for a given set of inputs. An individual process is single-minded in this regard: it simply executes the next statement in the program.

•

While executing, the process has access to certain data. In Java, there are three types of data a process can access: local variables are accessed from the thread's stack, instance variables are accessed through object references, and static variables are accessed through class or object references.

page 6

Java Threads, 2nd edition

Now consider what happens when you sit at your computer and start two single-threaded programs: a text editor, say, and a file manager. You now have two processes running on your computer; each process has a single thread with the properties just outlined. Each process does not necessarily know about the other process, although, depending on the operating system running on your computer, there are several ways in which the processes can send each other various messages. A common behavior is that you can drag a file icon from the file manager into the text editor in order to edit the file. Each process thus runs independently of the other, although they can cooperate if they so choose. The typical multitasking environment is shown in Figure 1.1. Figure 1.1. Processes in a multitasking environment

From the point of view of the person using the computer, these processes often appear to execute simultaneously, although many variables can affect that appearance. These variables depend on the operating system: for example, a given operating system may not support multitasking at all, so that no two programs appear to execute simultaneously. Or the user may have decided that a particular process is more important than other processes and hence should always run, shutting out the other processes from running and again affecting the appearance of simultaneity. Finally, the data contained within these two processes is, by default, separated: each has its own stack for local variables, and each has its own data area for objects and other data elements. Under many operating systems, the programmer can make arrangements so that the data objects reside in memory that can be shared between the processes, allowing both processes to access them.

1.2.2 Overview of Multithreading All of this leads us to a common analogy: we can think of a thread just as we think of a process, and we can consider a program with multiple threads running within a single instance of the Java virtual machine just as we consider multiple processes within an operating system, as we show in Figure 1.2. Figure 1.2. Multitasking versus threading

page 7

Java Threads, 2nd edition

So it is that within a Java program, multiple threads have these properties: •

Each thread begins execution at a predefined, well-known location. For one of the threads in the program, that location is the main() method; for the rest of the threads, it is a particular location the programmer decides on when the code is written. Note that this is true of an applet as well, in which case the main() method was executed by the browser itself.

•

Each thread executes code from its starting location in an ordered, predefined (for a given set of inputs) sequence. Threads are single-minded in their purpose, always simply executing the next statement in the sequence.

•

Each thread executes its code independently of the other threads in the program. If the threads choose to cooperate with each other, there are a variety of mechanisms we will explore that allow that cooperation. Exploiting those methods of cooperation is the reason why programming with threads is such a useful technique, but that cooperation is completely optional, much as the user is never required to drag a file from the file manager into the text editor.

•

The threads appear to have a certain degree of simultaneous execution. As we'll explore in Chapter 6, the degree of simultaneity depends on several factors - programming decisions about the relative importance of various threads as well as operating system support for various features. The potential for simultaneous execution is the key thing you must keep in mind when threading your code.

•

The threads have access to various types of data. At this point, the analogy to multiple processes breaks down somewhat, depending on the type of data the Java program is attempting to access. Each thread is separate, so that local variables in the methods that the thread is executing are separate for different threads. These local variables are completely private; there is no way for one thread to access the local variables of another thread. If two threads happen to execute the same method, each thread gets a separate copy of the local variables of that method. This is completely analogous to running two copies of the text editor: each process would have separate copies of the local variables. Objects and their instance variables, on the other hand, can be shared between threads in a Java program, and sharing these objects between threads of a Java program is much easier than sharing data objects between processes in most operating systems. In fact, the ability to share data objects easily between threads is another reason why programming with threads is so useful. But Java threads cannot arbitrarily access each other's data objects: they need permission to access the objects, and one thread needs to pass the object reference to the other thread. Static variables are the big exception to this analogy: they are automatically shared between all threads in a Java program.

Don't panic over this analogy: the fact that you'll be programming with threads in Java doesn't mean you'll necessarily be doing the system-level type of programming you'd need to perform if you were writing the multitasking operating system responsible for running multiple programs. The Java Thread API is designed to be simple and requires little specialized skill for most common tasks.

1.3 Why Threads? The notion of threading is so ingrained in Java that it's almost impossible to write even the simplest programs in Java without creating and using threads. And many of the classes in the Java API are already threaded, so that often you are using multiple threads without realizing it. Historically, threading was first exploited to make certain programs easier to write: if a program can be split into separate tasks, it's often easier to program the algorithm as separate tasks or threads. Programs that fall into this category are typically specialized and deal with multiple independent tasks.

page 8

Java Threads, 2nd edition

The relative rareness of these types of programs makes threading in this category a specialized skill. Often, these programs were written as separate processes using operating-system-dependent communication tools such as signals and shared memory spaces to communicate between processes. This approach increased system complexity. The popularity of threading increased when graphical interfaces became the standard for desktop computers because the threading system allowed the user to perceive better program performance. The introduction of threads into these platforms didn't make the programs any faster, but it did create an illusion of faster performance for the user, who now had a dedicated thread to service input or display output. Recently, there's been a flurry of activity regarding a new use of threaded programs: to exploit the growing number of computers that have multiple processors. Programs that require a lot of CPU processing are natural candidates for this category, since a calculation that requires one hour on a single-processor machine could (at least theoretically) run in half an hour on a two-processor machine, or 15 minutes on a four-processor machine. All that is required is that the program be written to use multiple threads to perform the calculation. While computers with multiple processors have been around for a long time, we're now seeing these machines become cheap enough to be very widely available. The advent of less expensive machines with multiple processors, and of operating systems that provide programmers with thread libraries to exploit those processors, has made threaded programming a hot topic, as developers move to extract every benefit from these new machines. Until Java, much of the interest in threading centered around using threads to take advantage of multiple processors on a single machine. However, threading in Java often has nothing at all to do with multiprocessor machines and their capabilities; in fact, the first Java virtual machines were unable to take advantage of multiple processors on a machine, and many implementations of the virtual machine still follow that model. However, there are also implementations of the virtual machine that do take advantage of the multiple processors that the computer may have. A correctly written program running in one of those virtual machines on a computer with two processors may indeed take roughly half the time to execute that it would take on a computer with a single processor. If you're looking to use Java to have your program scale to many processors, that is indeed possible when you use the correct virtual machine. However, even if your Java program is destined to be run on a machine with a single CPU, threading is still very important. The major reason threading is so important in Java is that Java has no concept of asynchronous behavior. This means that many of the programming techniques you've become accustomed to using in typical programs are not applicable in Java; instead, you must learn a new repertoire of threading techniques to handle these cases of asynchronous behavior. This is not to say there aren't other times when threads are a handy programming technique in Java; certainly it's easy to use Java for a program that implements an algorithm that naturally lends itself to threading. And many Java programs implement multiple independent behaviors. The next few sections cover some of the circumstances in which Java threads are a required component of the program, due to the need for asynchronous behavior or to the elegance that threading lends to the problem.

1.3.1 Nonblocking I/O In Java, as in most programming languages, when you try to get input from the user, you execute a read() method specifying the user's terminal (System.in in Java). When the program executes the read() method, the program will typically wait until the user types at least one character before it continues and executes the next statement. This type of I/O is called blocking I/O : the program blocks until some data is available to satisfy the read() method. This type of behavior is often undesirable. If you're reading data from a network socket, that data is often not available when you want to read it: the data may have been delayed in transit over the network, or you may be reading from a network server that sends data only periodically. If the program blocks when it tries to read from the socket, then it's unable to do anything else until the data is actually available.

page 9

Java Threads, 2nd edition

If the program has a user interface that contains a button and the user presses the button while the program is executing the read() method, nothing will happen: the program will be unable to process the mouse events and execute the event-processing method associated with the button. This can be very frustrating for the user, who thinks the program has hung. Traditionally, there are three techniques to cope with this situation: I/O multiplexing Developers often take all input sources and use a system call like select() to notify them when data is available from a particular source. This allows input to be handled much like an event from the user (in fact, many graphical toolkits use this method transparently to the user, who simply registers a callback function that is called whenever data is available from a particular source). Polling Polling allows a developer to test if data is available from a particular source. If data is available, the data can be read and processed; if it is not, the program can perform another task. Polling can be done either explicitly - with a system call like poll() - or, in some systems, by making the read() function return an indication that no data is immediately available. Signals A file descriptor representing an input source can often be set so that an asynchronous signal is delivered to the program when data is available on that input source. This signal interrupts the program, which processes the data and then returns to whatever task it had been doing. In Java, none of these techniques is directly available. There is limited support for polling via the available() method of the FilterInputStream class, but this method does not have the rich

semantics that polling typically has in most operating systems. To compensate for the lack of these features, a Java developer must set up a separate thread to read the data. This separate thread can block when data isn't available, and the other thread(s) in the Java program can process events from the user or perform other tasks. While this issue of blocking I/O can conceivably occur with any data source, it occurs most frequently with network sockets. If you're used to programming sockets, you've probably used one of these techniques to read from a socket, but perhaps not to write to one. Many developers, used to programming on a local area network, are vaguely aware that writing to a socket may block, but it's a possibility that many of them ignore because it can only happen under certain circumstances, such as a backlog in getting data onto the network. This backlog rarely happens on a fast local area network, but if you're using Java to program sockets over the Internet, the chances of this backlog happening are greatly increased; hence the chance of blocking while attempting to write data onto the network is also increased. So in Java, you may need two threads to handle the socket: one to read from the socket and one to write to it.

1.3.2 Alarms and Timers Traditional operating systems typically provide some sort of timer or alarm call: the program sets the timer and continues processing. When the timer expires, the program receives some sort of asynchronous signal that notifies the program of the timer's expiration. In Java, the programmer must set up a separate thread to simulate a timer. This thread can sleep for the duration of a specified time interval and then notify other threads that the timer has expired.

1.3.3 Independent Tasks A Java program is often called on to perform independent tasks. In the simplest case, a single applet may perform two independent animations for a web page. A more complex program would be a calculation server that performs calculations on behalf of several clients simultaneously. In either case, while it is possible to write a single-threaded program to perform the multiple tasks, it's easier and more elegant to place each task in its own thread.

page 10

Java Threads, 2nd edition

The complete answer to the question "Why threads?" really lies in this category. As programmers, we're trained to think linearly and often fail to see simultaneous paths that our program might take. But there's no reason why processes that we've conventionally thought of in a single-threaded fashion need necessarily remain so: when the Save button in a word processor is pressed, we typically have to wait a few seconds until we can continue. Worse yet, the word processor may periodically perform an autosave, which invariably interrupts the flow of typing and disrupts the thought process. In a threaded word processor, the save operation would be in a separate thread so that it didn't interfere with the work flow. As you become accustomed to writing programs with multiple threads, you'll discover many circumstances in which adding a separate thread will make your algorithms more elegant and your programs better to use.

1.3.4 Parallelizable Algorithms With the advent of virtual machines that can use multiple CPUs simultaneously, Java has become a useful platform for developing programs that use algorithms that can be parallelized. Any program that contains a loop is a candidate for being parallelized; that is, running one iteration of the loop on one CPU while another iteration of the loop is simultaneously running on another CPU. Dependencies between the data that each iteration of the loop needs may prohibit a particular loop from being parallelized, and there may be other reasons why a loop should not be parallelized. But for many programs with CPU-intensive loops, parallelizing the loop will greatly speed up the execution of the program when it is run on a machine with multiple processors. Many languages have compilers that support automatic parallelization of loops; as yet, Java does not. But as we'll see in Chapter 9, parallelizing a loop by hand is often not a difficult task.

1.4 Summary The idea of multiple threads of control within a single program may seem like a new and difficult concept, but it is not. All programs have at least one thread already, and multiple threads in a single program are not radically different from multiple programs within an operating system. A Java program can contain many threads, all of which may be created without the explicit knowledge of the developer. For now, all you need to consider is that when you write a Java application, there is an initial thread that begins its operation by executing the main() method of your application. When you write a Java applet, there is a thread that is executing the callback methods (init(), actionPerformed(), etc.) of your applet; we speak of this thread as the applet's thread. In either case, your program starts with what you can consider as a single thread. If you want to perform I/O (particularly if the I/O might block), start a timer, or do any other task in parallel with the initial thread, you must start a new thread to perform that task. In the next chapter, we'll examine how to do just that.

page 11

Java Threads, 2nd edition

Chapter 2. The Java ThreadingAPI In this chapter, we will create our own threads. As we shall see, Java threads are easy to use and well integrated with the Java environment.

2.1 Threading Using the Thread Class In the last chapter, we considered threads as separate tasks that execute in parallel. These tasks are simply code executed by the thread, and this code is actually part of our program. The code may download an image from the server or may play an audio file on the speakers or any other task; because it is code, it can be executed by our original thread. To introduce the parallelism we desire, we must create a new thread and arrange for the new thread to execute the appropriate code. Let's start by looking at the execution of a single thread in the following example: public class OurClass { public void run() { for (int I = 0; I < 100; I++) { System.out.println("Hello"); } } }

In this example, we have a class called OurClass. The OurClass class has a single public method called run() that simply writes a string 100 times to the Java console or to the standard output. If we execute this code from an applet as shown here, it runs in the applet's thread: import java.applet.Applet; public class OurApplet extends Applet { public void init() { OurClass oc = new OurClass(); oc.run(); } }

If we instantiate an OurClass object and call its run() method, nothing unusual happens. An object is created, its run() method is called, and the "Hello" message prints 100 times. Just like other method calls, the caller of the run() method waits until the run() method finishes before it continues. If we were to graph an execution of the code, it would look like Figure 2.1. Figure 2.1. Graphical representation of nonthreaded method execution

page 12

Java Threads, 2nd edition

What if we want the run() method of OurClass to execute in parallel with the init() and other methods of the applet? In order to do that, we must modify the OurClass class so that it can be executed by a new thread. So the first thing we'll do is make OurClass inherit from the Thread (java.lang.Thread) class: public class OurClass extends Thread { public void run() { for (int I = 0; I < 100; I++) { System.out.println("Hello"); } } }

If we compile this code and run it with our applet, everything works exactly as before: the applet's init() method calls the run() method of the OurClass object and waits for the run() method to return before continuing. The fact that this example compiles and runs proves that the Thread class exists. This class is our first look into the Java threading API and is the programmatic interface for starting and stopping our own threads. But we have not yet created a new thread of control; we have simply created a class that has a run() method. To continue, let's modify our applet like this: import java.applet.Applet; public class OurApplet extends Applet { public void init() { OurClass oc = new OurClass(); oc.start(); } }

In this second version of our applet, we have changed only one line: the call to the run() method is now a call to the start() method. Compiling and executing this code confirms that it still works and appears to the user to run exactly the same way as the previous example. Since the start() method is not part of the OurClass class, we can conclude that the implementation of the start() method is part of either the Thread class or one of its superclasses. Furthermore, since the applet still accomplishes the same task, we can conclude that the start() method causes a call, whether directly or indirectly, to the run() method. Upon closer examination, this new applet actually behaves differently than the previous version. While it is true that the start() method eventually calls the run() method, it does so in another thread. The start() method is what actually creates another thread of control; this new thread, after dealing with some initialization details, then calls the run() method. After the run() method completes, this new thread also deals with the details of terminating the thread. The start() method of the original thread returns immediately. Thus, the run() method will be executing in the newly formed thread at about the same time the start() method returns in the first thread, as shown in Figure 2.2. Figure 2.2. Graphical representation of threaded method execution

page 13

Java Threads, 2nd edition

Here are the methods of the Thread class that we've discussed so far: Thread() Constructs a thread object using default values for all options. void run() The method that the newly created thread will execute. Developers should override this method with the code they want the new thread to run; we'll show the default implementation of the run() method a little further on, but it is essentially an empty method. void start() Creates a new thread and executes the run() method defined in this thread class. To review, creating another thread of control is a two-step process. First, we must create the code that executes in the new thread by overriding the run() method in our subclass. Then we create the actual subclassed object using its constructor (which calls the default constructor of the Thread class in this case) and begin execution of its run() method by calling the start() method of the subclass.

run() Versus main() In essence, the run() method may be thought of as the main() method of the newly formed thread: a new thread begins execution with the run() method in the same way a program begins execution with the main() method. While the main() method receives its arguments from the argv parameter (which is typically set from the command line), the newly created thread must receive its arguments programmatically from the originating thread. Hence, parameters can be passed in via the constructor, static instance variables, or any other technique designed by the developer.

2.1.1 Animate Applet Let's see a more concrete example of creating a new thread. When you want to show an animation in your web page, you do so by displaying a series of images (frames) with a time interval between the frames. This use of a timer is one of the most common places in Java where a separate thread is required: because there are no asynchronous signals in Java, you must set up a separate thread, have the thread sleep for a period of time, and then have the thread tell the applet to paint the next frame. An implementation of this timer follows: import java.awt.*; public class TimerThread extends Thread { Component comp; // Component that needs repainting int timediff; // Time between repaints of the component volatile boolean shouldRun; // Set to false to stop thread public TimerThread(Component comp, int timediff) { this.comp = comp; this.timediff = timediff; shouldRun = true; } public void run() { while (shouldRun) { try { comp.repaint(); sleep(timediff); } catch (Exception e) {} } } }

page 14

Java Threads, 2nd edition

In this example, the TimerThread class, just like the OurClass class, inherits from the Thread class and overrides the run() method. Its constructor stores the component on which to call the repaint() method and the requested time interval between the calls to the repaint() method. What we have not seen so far is the call to the sleep() method: static void sleep (long milliseconds) Puts the currently executing thread to sleep for the specified number of milliseconds. This method is static and may be accessed through the Thread class name. static void sleep (long milliseconds, int nanoseconds) Puts the currently executing thread to sleep for the specified number of milliseconds and nanoseconds. This method is static and may be accessed through the Thread class name. The sleep() method is part of the Thread class, and it causes the current thread (the thread that made the call to the sleep() method) to pause for the specified amount of time in milliseconds. The try statement in the code example is needed due to some of the exceptions that are thrown from the sleep() method. We'll discuss these exceptions in Appendix B; for now, we'll just discard all exceptions. The easiest description of the task of the sleep() method is that the caller actually sleeps for the specified amount of time. This method is part of the Thread class because of how the method accomplishes the task: the current (i.e., calling) thread is placed in a "blocked" state for the specified amount of time, much like the state it would be in if the thread were waiting for I/O to occur. See Appendix A for a discussion of the volatile keyword.

sleep(long) and sleep(long, int) The Thread class provides a version of the sleep() method that allows the developer to specify the time in terms of nanoseconds. Unfortunately, most operating systems that implement the Java virtual machine do not support a resolution as small as a nanosecond. For those platforms, the method simply rounds the number of nanoseconds to the nearest millisecond and calls the version of the sleep() method that only specifies milliseconds. In fact, most operating systems do not support a resolution of a single millisecond, so that the milliseconds are in turn rounded up to the smallest resolution that the platform supports. For the developer, we should note that support of nanoseconds may never be available in all versions of the Java virtual machine. As a matter of policy, one should not design programs that require support of nanoseconds (or even exact timing of milliseconds) in order to function correctly.

To return to step 2 of the two-step process: let's take a look at the Animate applet that uses our TimerThread class: import java.applet.*; import java.awt.*; public class Animate extends Applet { int count, lastcount; Image pictures[]; TimerThread timer; public void init() { lastcount = 10; count = 0; pictures = new Image[10]; MediaTracker tracker = new MediaTracker(this); for (int a = 0; a < lastcount; a++) { pictures[a] = getImage ( getCodeBase(), new Integer(a).toString()+".jpeg"); tracker.addImage(pictures[a], 0); } tracker.checkAll(true); } page 15

Java Threads, 2nd edition

public void start() { timer = new TimerThread(this, 1000); timer.start(); } public void stop() { timer.shouldRun = false; timer = null; } public void paint(Graphics g) { g.drawImage(pictures[count++], 0, 0, null); if (count == lastcount) count = 0; } }

Here we create and start the new thread in the applet's start() method. This new thread is responsible only for informing the applet when to redraw the next frame; it is still the applet's thread that performs the redraw when the applet's paint() method is called. The init() method in this case simply loads the image frames from the server.

2.1.2 Stopping a Thread When the stop() method of the applet is called, we need to stop the timer thread, since we do not need repaint() requests when the applet is no longer running. To do this, we relied on the ability to set the shouldRun variable of the TimerThread class to notify that class that it should return from its run() method. When a thread returns from its run() method, it has completed its execution, so in this case we also set the timer instance variable to null to allow that thread object to be garbage collected. This technique is the preferred method for terminating a thread: threads should always terminate by returning from their run() method. It's up to the developer to decide how a thread should know when it's time to return from the run() method; setting a flag, as we've done in this case, is typically the easiest method to do that. Setting a flag means that my thread has to check the flag periodically. Isn't there a cleaner way to stop the thread? And isn't there a way to terminate the thread immediately, rather than waiting for it to check some flag? Well, yes and no. The Thread class does contain a stop() method that allows you to stop a thread immediately: no matter what the thread is doing, it will be terminated. However, the stop() method is very dangerous. In Java 2, the stop() method is deprecated; however, the reasons that led it to become deprecated actually exist in all versions of Java, so you should avoid using the stop() method in any release of Java. We'll discuss the motivation for this in Chapter 6 after we understand a little more about the details of threaded programming; for now, you'll have to accept our word that using the stop() method is a dangerous thing. In addition, calling the stop() method will sometimes result in a security exception, as we'll explain in Chapter 10, so you cannot rely on it always working.

The start() and stop() Methods of the Applet Class It is unfortunate that both the Applet and the Thread classes have a start() and a stop() method, and that they have the same signature in both classes. This may be a source of confusion when implementing or debugging threaded applets. These methods serve different purposes and are not directly related to each other.

page 16

Java Threads, 2nd edition

For the record, here is the definition of the stop() method: void stop() (deprecated in Java 2) Terminates an already running thread. What does returning from the run() method (or calling the stop() method) accomplish? As we mentioned, when the run() method completes, the thread automatically handles the cleanup process and other details of terminating the thread. The stop() method simply provides a way of prematurely terminating the run() method. The thread will then, as usual, automatically handle the cleanup process and other details of terminating the thread. Details of how the stop() method actually works are given in Appendix A.

2.2 Threading Using the Runnable Interface As simple as it is to create another thread of control, there is one problem with the technique we've outlined so far. It's caused by the fact that Java classes can inherit their behavior only from a single class, which means that inheritance itself can be considered a scarce resource, and is therefore "expensive" to the developer. In our example, we are threading a simple loop, so this is not much of a concern. However, if we have a complete class structure that already has a detailed inheritance tree and want it to run in its own thread, we cannot simply make this class structure inherit from the Thread class as we did before. One solution would be to create a new class that inherits from Thread and contains references to the instances of the classes we need. This level of indirection is an annoyance. The Java language deals with this lack of multiple inheritance by using the mechanism known as interfaces.[1] This mechanism is supported by the Thread class and simply means that instead of inheriting from the Thread class, we can implement the Runnable interface (java.lang.Runnable), which is defined as follows: [1] It can be argued that interfaces cannot accomplish everything that multiple inheritance can, but that is a debate for a different book.

public interface Runnable { public abstract void run(); }

The Runnable interface contains only one method: the run() method. The Thread class actually implements the Runnable interface; hence, when you inherit from the Thread class, your subclass also implements the Runnable interface. However, in this case we want to implement the Runnable interface without actually inheriting from the Thread class. This is achieved by simply substituting the phrase "implements Runnable" for the phrase "extends Thread"; no other changes are necessary in step 1 of our thread creation process: public class OurClass implements Runnable { public void run() { for (int I = 0; I < 100; I++) { System.out.println("Hello, from another thread"); } } }

Step 2 of our thread creation processes has some other changes. Since an instance of the OurClass class is no longer a Thread object, it cannot be treated as one. So in order to create a separate thread of control, an instance of the Thread class is still needed, but it will be instantiated with a reference to our OurClass object. In other words, its usage is slightly more complicated: import java.applet.Applet; public class OurApplet extends Applet { public void init() { Runnable ot = new OurClass(); Thread th = new Thread(ot); th.start(); } }

page 17

Java Threads, 2nd edition

As before, we have to create an instance of the OurClass class. However, in this new version, we also need to create an actual thread object. We create this object by passing our runnable OurClass object reference to the constructor of the thread using a new constructor of the Thread class: Thread(Runnable target) Constructs a new thread object associated with the given Runnable object. The new Thread object's start() method is called to begin execution of the new thread of control. The reason we need to pass the runnable object to the thread object's constructor is that the thread must have some way to get to the run() method we want the thread to execute. Since we are no longer overriding the run() method of the Thread class, the default run() method of the Thread class is executed; this default run() method looks like this: public void run() { if (target != null) { target.run(); } }

Here, target is the runnable object we passed to the thread's constructor. So the thread begins execution with the run() method of the Thread class, which immediately calls the run() method of our runnable object. Interestingly, since we can use the Runnable interface instead of inheriting from the Thread class, we can merge the OurClass class into the applet itself. This is a common technique for spinning off a separate thread of control for the applet. Since the applet itself is now runnable, instance variables of the applet thread and the run() method in this newly spun-off thread are the same: import java.applet.Applet; public class OurApplet extends Applet implements Runnable { public void init() { Thread th = new Thread(this); th.start(); } public void run() { for (int I = 0; I < 100; I++) { System.out.println("Hello, from another thread"); } } }

This technique can also be used with our Animate class: import java.applet.*; import java.awt.*; public class Animate extends Applet implements Runnable { int count, lastcount; Image pictures[]; Thread timer; public void init() { lastcount = 10; count = 0; pictures = new Image[10]; MediaTracker tracker = new MediaTracker(this); for (int a = 0; a < lastcount; a++) { pictures[a] = getImage ( getCodeBase(), new Integer(a).toString()+".jpeg"); tracker.addImage(pictures[a], 0); } tracker.checkAll(true); } public void start() { if (timer == null) { timer = new Thread(this); timer.start(); } }

page 18

Java Threads, 2nd edition

public void paint(Graphics g) { g.drawImage(pictures[count++], 0, 0, null); if (count == lastcount) count = 0; } public void run() { while (isActive()) { try { repaint(); Thread.sleep(1000); } catch (Exception e) {} } timer = null; } }

After merging the classes, we now have a direct reference to the applet, so we can call the repaint() method directly. Because the Animate class is not of the Thread class, its run() method cannot call the sleep() method directly. Fortunately, the sleep() method is a static method, so we can still access it using the Thread class specifier. As can be seen from this example, the threading interface model allows classes that already have fixed inheritance structures to be threaded without creating a new class. However, there is still one unanswered question: when should you use the Runnable interface and when should you create a new subclass of Thread?

The isActive() Method We used the isActive() method in the last example instead of stopping the thread explicitly. This shows another technique you can use to stop your threads; the benefit of this technique is that it allows the run() method to terminate normally rather than through the immediate termination caused by the stop() method. This allows the run() method to clean up after itself before it terminates. The isActive() method is part of the Applet class and determines if an applet is active. By definition, an applet is active between the periods of the applet's start() and stop() methods. Don't confuse this method with the isAlive() method of the Thread class, which we'll discuss later.

Does threading by the Runnable interface solve a problem that cannot be solved through threading by inheritance or vice versa? At this point, there do not seem to be any significant differences between the two techniques. It is easier to use one technique for certain tasks and the other technique for other tasks. For example, our last Animate class saved us the need to have an extra class definition, via its use of the Runnable interface in the Applet class. In the earlier example, having a separate TimerThread definition may have been both easier to understand and to debug. But these differences are relatively minor, and there do not seem to be any tasks that cannot be solved by either technique. At this point, we will not worry about the difference between the two techniques. We will use one technique or the other based on personal preference and the clarity of the solution. As we develop examples throughout this book, we hope that you will learn to use either technique on a case-by-case basis. This is all there is to writing simple threaded Java programs. We have a class that allows us to define a method that will be executed in a separate thread; this thread can be initiated via its start() method, and it should stop by returning from its run() method. However, as we have seen in the previous chapter, it is not just the ability to have different threads that makes the threaded system a powerful tool; it is that these threads can communicate easily with each other by invoking methods on objects that are shared between the threads.

page 19

Java Threads, 2nd edition

Inheritance or Interfaces? As noted, we will choose threading with inheritance or interfaces based on personal preference and the clarity of the solution. However, those of you who are object-oriented purists could argue that unless we are enhancing the Thread class, we should not inherit from the Thread class. Theorists could insert an entire chapter on this issue. Our main concern is for the clarity of the code; any other reasons for choosing between threading by inheritance or interfaces are beyond the scope of this book.

2.3 The Life Cycle of a Thread So far, we have a simple knowledge of working with threads: we know how to use the start() method to start a thread, and how to terminate a thread by arranging for its run() method to complete. We'll now look at two techniques that provide us more information about the thread during its life cycle.

2.3.1 The isAlive() Method There is a period of time after you call the start() method before the virtual machine can actually start the thread. Similarly, when a thread returns from its run() method, there is a period of time before the virtual machine can clean up after the thread; and if you use the stop() method, there is an even greater period of time before the virtual machine can clean up after the thread. This delay occurs because it takes time to start or terminate a thread; therefore, there is a transitional period from when a thread is running to when a thread is not running, as shown in Figure 2.3. After the run() method returns, there is a short period of time before the thread stops. If we want to know if the start() method of the thread has been called - or, more usefully, if the thread has terminated we must use the isAlive() method. This method is used to find out if a thread has actually been started and has not yet terminated: boolean isAlive() Determines if a thread is considered alive. By definition, a thread is considered alive from sometime before a thread is actually started to sometime after a thread is actually stopped. Figure 2.3. Graphical representation of the states of the thread

page 20

Java Threads, 2nd edition

Let's modify our Animate class to wait until the timer thread stops before finishing: import java.applet.*; import java.awt.*; public class Animate extends Applet { int count, lastcount; Image pictures[]; TimerThread timer; public void init() { lastcount = 10; count = 0; pictures = new Image[10]; MediaTracker tracker = new MediaTracker(this); for (int a = 0; a < lastcount; a++) { pictures[a] = getImage( getCodeBase(), new Integer(a).toString()+".jpeg"); tracker.addImage(pictures[a], 0); } tracker.checkAll(true); } public void start() { timer = new TimerThread(this, 1000); timer.start(); } public void stop() { timer.shouldRun = false; while (timer.isAlive()) { try { Thread.sleep(100); } catch (InterruptedException e) {} } timer = null; } public void paint(Graphics g) { g.drawImage(pictures[count++], 0, 0, null); if (count == lastcount) count = 0; } }

Just because a thread has been started does not mean it is actually running, nor that it is able to run the thread may be blocked, waiting for I/O, or it may still be in the transitional period of the start() method. For this reason, the isAlive() method is more useful in detecting whether a thread has stopped running. For example, let's examine the stop() method of this applet. Just like the earlier versions, we have a TimerThread object that is started and stopped when the applet is started and stopped. In this newer version, the applet's stop() method does more than just stop the TimerThread: it also checks to make sure the thread actually has stopped. In this example, we don't gain anything by making sure the timer thread has actually stopped. But if for some reason we need to deal with common data that is being accessed by two threads, and it is critical to make sure the other thread is stopped, we can simply loop and check to make sure the thread is no longer alive before continuing. There is another circumstance in which a thread can be considered no longer alive: if the stop() method is called, the thread will be considered no longer alive a short time later. This is really the same case: the isAlive() method can be used to determine if the run() method has completed, whether normally or as a result of the stop() method having been called.

2.3.2 Joining Threads The isAlive() method can be thought of as a crude form of communication. We are waiting for information: the indication that the other thread has completed. As another example, if we start a couple of threads to do a long calculation, we are then free to do other tasks. Assume that sometime later we have completed all other secondary tasks and need to deal with the results of the long calculation: we need to wait until the calculations are finished before continuing on to process the results.

page 21

Java Threads, 2nd edition

We could accomplish this task by using the looping isAlive() technique we've just discussed, but there are other techniques in the Java API that are more suited to this task. This act of waiting is called a thread join. We are "joining" with the thread that was "forked" off from us earlier when we started the thread. So, modifying our last example, we have: import java.applet.Applet; public class Animate extends Applet { ... public void stop() { t.shouldRun = false; try { t.join(); } catch (InterruptedException e) {} } }

The Thread class provides the following join() methods: void join() Waits for the completion of the specified thread. By definition, join() returns as soon as the thread is considered "not alive." This includes the case in which the join() method is called on a thread that has not been started. void join(long timeout) Waits for the completion of the specified thread, but no longer than the timeout specified in milliseconds. This timeout value is subject to rounding based on the capabilities of the underlying platform. void join(long timeout, int nanos) Waits for the completion of the specified thread, but no longer than a timeout specified in milliseconds and nanoseconds. This timeout value is subject to rounding based on the capabilities of the underlying platform. When the join() method is called, the current thread will simply wait until the thread it is joining with is no longer alive. This can be caused by the thread not having been started, or having been stopped by yet another thread, or by the completion of the thread itself. The join() method basically accomplishes the same task as the combination of the sleep() and isAlive() methods we used in the earlier example. However, by using the join() method, we accomplish the same task with a single method call. We also have better control over the timeout interval, and we don't waste CPU cycles by polling. Another interesting point about both the isAlive() method and the join() method is that we are actually not affecting the thread on which we called the method. That thread will run no differently whether the join() method is called or not; instead, it is the calling thread that is affected. The isAlive() method simply returns the status of a thread, and the join() method simply waits for a certain status on the thread.

join(), isAlive(), and the Current Thread The concept of a thread calling the isAlive() or the join() method on itself does not make sense. There is no reason to check if the current thread is alive since it would not be able to do anything about it if it were not alive. As a matter of fact, isAlive() can only return true when it checks the status of the thread calling it. If the thread were stopped during the isAlive() method, the isAlive() method would not be able to return. So a thread that calls the isAlive() method on itself will always receive true as the result. The concept of a thread joining itself does not make sense, but let's examine what happens when one tries. It turns out that the join() method uses the isAlive() method to determine when to return from the join() method. In the current implementation, it also does not check to see if the thread is joining itself. In other words, the join() method returns when and only when the thread is no longer alive. This will have the effect of waiting forever.

page 22

Java Threads, 2nd edition

2.4 Thread Naming The next topic we will examine concerns the thread support methods that are used mainly for thread "bookkeeping." First, it is possible to assign a String name to the Thread object itself: void setName(String name) Assigns a name to the Thread instance. String getName() Gets the name of the Thread instance. The Thread class provides a method that allows us to attach a name to the thread object and a method that allows us to retrieve the name. The system does not use this string for any specific purpose, though the name is printed out by the default implementation of the toString() method of the thread. The developer who assigns the name is free to use this string for any purpose desired. For example, let's assign a name to our TimerThread class: import java.awt.*; public class TimerThread extends Thread { Component comp; int timediff; volatile boolean shouldRun;

// Component that needs repainting // Time between repaints of the component // Set to false to stop thread

public TimerThread(Component comp, int timediff) { this.comp = comp; this.timediff = timediff; shouldRun = true; setName("TimerThread(" + timediff + " milliseconds)"); } public void run() { while (shouldRun) { try { comp.repaint(); sleep(timediff); } catch (Exception e) {} } } }

In this version of the TimerThread class, we assigned a name to the thread. The name that is assigned is simply "TimerThread" followed by the number of milliseconds used in this timer thread. If the getName() method is later called on this instance, this string value will be returned.

Uses for a Thread Name? Using the thread name to store information is not too beneficial. We could just as easily have added an instance variable to the Thread class (if we're threading by inheritance) or to the Runnable type class (if we're threading by interfaces) and achieved the same results. The best use of this name is probably for debugging. With an assigned name, the debugger and the toString() method display thread information in terms of a "logical" name instead of a number. By default, if no name is assigned, the Thread class chooses a unique name. This name is generally "Thread-" followed by a unique number.

page 23

Java Threads, 2nd edition

The naming support is also available as a constructor of the Thread class: Thread(String name) Constructs a thread object with a name that is already assigned. This constructor is used when threading by inheritance. Thread(Runnable target, String name) Constructs a thread object that is associated with the given Runnable object and is created with a name that is already assigned. This constructor is used when threading by interfaces. Just like the setName() method, setting the name via the thread constructor is simple. One constructor is provided for threading by inheritance and another for threading by interfaces. In our TimerThread example, since we are setting the name in the constructor, we could just as easily have used the thread constructor instead of the setName() method: import java.awt.*; public class TimerThread extends Thread { Component comp; // Component that needs repainting int timediff; // Time between repaints of the component volatile boolean shouldRun; // Set to false to stop thread public TimerThread(Component comp, int timediff) { super("TimerThread(" + timediff + " milliseconds)"); this.comp = comp; this.timediff = timediff; shouldRun = true; } public void run() { while (shouldRun) { try { comp.repaint(); sleep(timediff); } catch (Exception e) {} } } }

2.5 Thread Access Next, we'll look into several methods that show us information about specific threads.

2.5.1 The Current Thread First, we'll examine the currentThread() method: static Thread currentThread() Gets the Thread object that represents the current thread of execution. The method is static and may be called through the Thread class name. This is a static method of the Thread class, and it simply returns a Thread object that represents the current thread; the current thread is the thread that called the currentThread() method. The object returned is the same Thread object first created for the current thread. But why is this method important? The Thread object for the current thread may not be saved anywhere, and even if it is, it may not be accessible to the called method. For example, let's look at a class that performs socket I/O and stores the data it reads into an internal buffer. We'll show the full implementation of this class in the next chapter, but for now, we're interested only in its interface:

page 24

Java Threads, 2nd edition

public class AsyncReadSocket extends Thread { StringBuffer result; public AsyncReadSocket(String host, int port) { // Open a socket to the given host. } public void run() { // Read data from a socket into the result string buffer. } // Get the string already read from the socket so far. // Only allows "Reader" threads to execute this method. public String getResult() { String reader = Thread.currentThread().getName(); if (reader.startsWith("Reader")) { String retval = result.toString(); result = new StringBuffer(); return retval; } else { return ""; } } }

To retrieve the data that has been read by this class, you must call the getResult() method, but we've coded the getResult() method such that only reader threads are allowed actually to retrieve the stored data. For our example, we are assuming that reader threads are threads whose names start with "Reader." This name could have been assigned by the setName() method earlier or when the threads are constructed. To obtain a name, we need simply to call the getName() method. However, since we do not have the Thread object reference of the caller, we must call the currentThread() method to obtain the reference. In this case, we are using the name of the thread, but we could just as easily have used the thread reference for other purposes. Other uses of the thread reference could be priority control or thread groups; these and other services are described in upcoming chapters. Note that there is a very subtle thing going on here. The getName() method is a method of the Thread class, and we might have called it directly in our code. That would return the name of the AsyncReadSocket thread itself. Instead, what we're after is the name of the thread that has called the getResult() method, which is probably not the AsyncReadSocket thread. Typically, we'd use the AsyncReadSocket class like this: public class TestRead extends Thread { AsyncReadSocket asr; public static void main(String args[]) { AsyncReadSocket asr = new AsyncReadSocket("myhost", 6001); asr.start(); new TestRead(asr).start(); } public TestRead(AsyncReadSocket asr) { super("ReaderThread"); this.asr = asr; } public void run() { // Do some other processing, and allow asr to read data. System.out.println("Data is " + asr.getResult()); } }

There are three threads of interest to us in this example: the thread that the virtual machine started for us that is executing the main() method, the asr thread, and the TestRead thread. Since the TestRead thread is executing the getResult() method, it will actually receive the data, as its name begins with "Reader." If another thread in this example were to call the getResult() method, it would receive merely an empty string. This can be a common source of confusion: methods in subclasses of the thread class may be executed by the thread object itself, or they may - like the get-Result() method in this example - be executed by another thread object. Don't assume that the code in a thread object is only being executed by the specific thread that the object represents.

page 25

Java Threads, 2nd edition

2.5.2 Enumerating Threads in the Virtual Machine Also provided with the Thread class are methods that allow you to obtain a list of all the threads in the program: static int enumerate(Thread threadArray[]) Gets all the thread objects of the program and stores the result into the thread array. The value returned is the number of thread objects stored into the array. The method is static and may be called through the Thread class name. static int activeCount() Returns the number of threads in the program. The method is static and may be called through the Thread class name. This list is retrieved with the enumerate() method. The developer simply needs to create a Thread array and pass it as a parameter. The enumerate() method stores the thread references into the array and returns the number of thread objects stored; this number is the size of the array parameter or the number of threads in the program, whichever is smaller. In order to size the array for the enumerate() method, we need to determine the number of threads in the program. The activeCount() method can determine the number of threads and size the thread array accordingly. For example, we could add a support method to our Animate applet that prints all the threads in the applet, as follows: import java.applet.*; import java.awt.*; public class Animate extends Applet { // Instance variables and methods not shown public void printThreads() { Thread ta[] = new Thread[Thread.activeCount()]; int n = Thread.enumerate(ta); for (int i = 0; i < n; i++) { System.out.println("Thread " + i + " is " + ta[i].getName()); } } }

In this example, we are instantiating a Thread array; the size of the array is determined by the activeCount() method of the Thread class. Once we have an active count, we call the enumerate() method to obtain references to all the thread objects in our applet. In the rest of the method, we simply print the name assigned to each thread by calling the getName() method on the thread reference.

Trivia: When Is a Thread Active? When is a thread active? At first glance, this seems to be a simple question. Using the isAlive() method, a thread is considered alive during the period between the call to the start() method and a short time period after the stop() method is called. We might consider a thread active if it is alive. However, if the definition of an active thread is a thread whose thread reference appears in the active count returned by the activeCount() method, we would have a different definition of active. A thread reference first appears in the thread array returned by the enumerate() method, and is counted by the activeCount() method, when the thread object is first constructed and not when the thread is started. The thread is removed from the thread array either when the thread is stopped or when the run() method has completed. This means that if a thread object is constructed but is not

started, the thread object will not be removed from the enumeration list, even if the original reference to the object is lost.

page 26

Java Threads, 2nd edition

Note that we've been careful in this section to say "all the threads in the program" rather than "all the threads in the virtual machine." That's because at the level of the Thread class, the enumerate() method shows us only the threads that our program has created, plus (possibly) the main and GUI threads of an application or applet that the virtual machine has created for us. It will not show us other threads of the virtual machine (e.g., the garbage collection thread), and in an applet, it will not show us other threads in other applets. We'll see how to examine all these other threads in Chapter 10.

2.6 More on Starting, Stopping, and Joining Consider this revision to the Animate example: import java.applet.Applet; public class Animate extends Applet { TimerThread t; public void start() { if (t == null) t = new TimerThread(this, 500); t.start(); } public void stop() { t.shouldRun = false; try { t.join(); } catch (InterruptedException e) {} // t = null; } }

In our last version of the Animate applet (see Section 2.3," earlier in this chapter), the start() method of the applet created a new TimerThread object and started it. But what if we had only created the TimerThread once? In the example just shown, we once again create a new TimerThread in the start() method of the applet; however, since we know the thread will be stopped in the stop() method, we try to restart the stopped thread in the start() method. In other words, we create the TimerThread only once and use this one thread object to start and stop the animation. By starting and stopping a single TimerThread, we do not need to create a new instance of TimerThread every time the applet is started, and the garbage collector will not need to clean up the TimerThread instance that's left when the applet is stopped and the TimerThread dereferenced. But will this work? Unfortunately, the answer is no. It turns out that when a thread is stopped, the state of the thread object is set so that it is not restartable. In our case, when we try to restart the thread by calling the TimerThread's start() method, nothing happens. The start() method won't return an exception condition, but the run() method also won't be called. The isAlive() method also won't return true. In other words, never restart a thread. An instance of a thread object should be used once and only once.

More Details for Restarting a Thread What happens when you try to restart a thread? The answer is that it actually depends on when you restart it. When the stop() method is called on a thread (or the thread exits its run() method), it actually takes time for the thread to stop. Hence, what happens when the start() method is called depends on a race condition . (Race conditions are discussed more fully in Chapter 3.) If the start() method is called before the stopping thread actually stops, an error condition exists, and an exception will be thrown. The same is true if you call start() on a thread object that has not been stopped. If the start() method is called after the stopping thread has actually stopped, nothing happens: the thread object is in a state where it cannot be restarted.

page 27

Java Threads, 2nd edition

Can an already stopped thread be stopped? At first glance, this may seem an odd question. But the answer is yes, and the reason is that it avoids a race condition that would occur otherwise. We know there are two ways a thread can be stopped, so you could stop a thread that has already exited because its run() method terminated normally. If the Thread class did not allow the stop() method to be called on a stopped thread, this would require us to check if the thread was still running before we stopped it, and we'd have to avoid a race condition in which the run() method could terminate in between the time when we checked if the thread was alive and when we called the stop() method. This would be a big burden on the Java developer, so, instead, the stop() method can be called on a thread that has already stopped. What happens when we call the join() method for a thread that was stopped a long time ago? In the examples so far, we assumed the usage of the join() method was to wait for a thread to complete or to stop. But this assumption is not necessary; if the thread is already stopped, it will return immediately. This may seem obvious, but it should be noted that a race condition would have resulted if the join() method had required that the thread be alive when the method was first called.

The Stopping Thread and the Garbage Collector The thread object, like any other object, is a candidate for garbage collection when it gets dereferenced. As developers, we should just note that the garbage collector behaves correctly with the threading system and not worry about the exact details. However, for those of us who are detail-oriented, here is how the garbage collector behaves with the threading system. In all the examples so far, the garbage collector cannot collect the thread object even when the thread has completed or stopped. This is because we still have a reference to the TimerThread object after we signal it to stop. To be complete, we should manually dereference the thread object. However, this is necessary only to free the memory that stores the thread object. The threading system automatically releases any thread-specific resources (including those tied to the operating system) after the thread has completed or stopped whether or not we dereference the object. Dereferencing a thread object for a running thread is also not a problem. The threading system keeps references to all threads that are running in the system. This is needed in order to support the currentThread() and enumerate() methods of the Thread class. The garbage collector will not be able to collect the thread object until the threading system also dereferences the object, which won't happen until the thread is no longer alive.

What would be the best way to join() with more than one thread? Let's look at the following code: import java.applet.Applet; public class MyJoinApplet extends Applet { Thread t[] = new Thread[30]; public void start() { for (int i=0; i t3 -> t1 -> NULL BLOCKED: SimpleScheduler -> NULL

At this point, t1 is the currently running thread, and we'll start to see output lines that say "Thread 1." When SimpleScheduler wakes up, it moves to the runnable state and, because it is the highest priority thread in the Java virtual machine, it becomes the currently running thread: PRIORITY 5: t2 -> t3 -> t1 -> NULL PRIORITY 10: SimpleScheduler -> NULL

SimpleScheduler immediately executes the sleep() method, moving it back to the blocked state; the Java virtual machine then selects the next thread in the list (t2) as the currently running thread and moves it to the end of the list: PRIORITY 5: t3 -> t1 -> t2 -> NULL BLOCKED: SimpleScheduler -> NULL

As this continues, each thread in the list of threads at priority 5 becomes the currently running thread in turn. This scheduler requires that the virtual machine reorder the threads on a priority list whenever one of them is selected to run. As we mentioned in the last chapter, this is almost universally the case, but it is not a requirement of the Java specification, and we know of one real-time operating system on which this scheduling mechanism does not work. Note that this mechanism still works for native-thread implementations. On a Windows implementation, the effect is that the currently running thread changes more often than specified by the sleep value within the SimpleScheduler, since the operating system will sometimes change the currently running thread while the scheduler is sleeping. On a Solaris implementation, the reordering of the threads will be dependent on the number of LWPs, but the interruption is sufficient to cause a single LWP to schedule another thread, which achieves the desired effect.

page 123

Java Threads, 2nd edition

7.2.2 A More Complete Scheduler Now we'll look into building a more complete scheduler that will schedule our threads in a roundrobin fashion. We can also use it to limit round-robin scheduling on native-thread platforms that timeslice as their default behavior; this limiting is achieved simply by using a very large value as the timeslice that the scheduler gives to a particular thread. However, since there are circumstances on native-thread platforms where the highest priority thread is not necessarily the currently running thread, we cannot completely prevent some sort of round-robin scheduling on those platforms: the best we can do is to use this scheduler to bias the operating system to favor one particular thread. The example we outline in this section assumes that there is a single CPU. If you need to use this technique on a machine with multiple CPUs, you will need to adjust the scheduler so that it creates N currently running threads rather than one currently running thread (where N is the number of processors on the machine). As written, this technique will work on machines with multiple processors - that is, it will prevent any CPU starvation - but it will have less of an effect on the overall scheduling of the threads. We'll start building this scheduler by establishing threads at three priority levels: Level 6 The scheduler itself is a separate thread running at level 6. This allows it to run in favor of the default threads created by the Java virtual machine and APIs and in favor of any threads the scheduler is controlling. This thread spends most of its time sleeping (i.e., blocked), so it doesn't usually become the currently running thread. Level 4 The scheduler selects one thread from all the threads it is controlling and assigns that thread a priority value of 4. Most of the time, this is the nonblocked thread with the highest priority in the Java virtual machine, so it is the thread favored to become the currently running thread. Level 2 All remaining threads under control of our scheduler run at priority level 2. Since there is always a thread running at level 4, these threads usually do not run at this priority; they remain at this priority until they are selected by our scheduler to have a priority level of 4, at which time they become favored to be the currently running thread. The idea behind the scheduler is that the programmer assigns certain threads to be under control of the scheduler. The scheduler selects one and only one of these threads and assigns it a priority of 4, while the rest of the threads have a priority of 2. The priority 4 thread is the currently running thread; from time to time, the scheduler itself wakes up and selects a different thread as the single priority 4 thread. On green-thread platforms, the priority 4 thread will always be selected as the currently running thread; on native-thread platforms, it will usually be selected as the currently running thread. For all the threads in this scheduling system - the scheduler thread itself plus any threads the programmer designates to be controlled by our scheduler - it is clear that no CPU starvation will occur: the scheduler thread will always run when it needs to, and as long as that thread correctly adjusts the priorities of the remaining threads under its control, all other threads will get their opportunity to become the currently running thread. In order to keep track of all the threads, we'll use the CircularList we developed in Chapter 5. This class gives us the queueing behavior we need to keep track of the threads under the control of our scheduler: we can add threads to the list with its insert() method, remove them with its delete() method, and, more important, go through the list by repeatedly calling its getNext() method.

page 124

Java Threads, 2nd edition

Here's the first pass at our scheduler: public class CPUScheduler extends Thread { private int timeslice; // # of milliseconds thread should run private CircularList threads; // All the threads we're scheduling public volatile boolean shouldRun = false; // Exit when this is set public CPUScheduler(int t) { threads = new CircularList(); timeslice = t; } public void addThread(Thread t) { threads.insert(t); t.setPriority(2); } public void removeThread(Thread t) { t.setPriority(5); threads.delete(t); } public void run() { Thread current; setPriority(6); while (shouldRun) { current = (Thread) threads.getNext(); if (current == null) return; current.setPriority(4); try { Thread.sleep(timeslice); } catch (InterruptedException ie) {}; current.setPriority(2); } } }

Although there are some necessary adjustments that we'll add to this scheduler throughout the rest of this chapter, this code is the essence of the scheduler. The refinements that we'll add are important in terms of making the class robust and thread safe, but they don't add to the basic functionality: we want to understand the functionality before we look at some of the subtle issues involved in this class. The programmer uses two methods to interface with the scheduler: addThread(), which adds a thread to the list of thread objects under control of the scheduler, and removeThread(), which removes a thread object from that list.[1] There's a subtle error here, in that when the thread is removed from the scheduler, we assign it the default thread priority rather than the priority it had when it was added to the scheduler. The correct practice would be to save the thread's priority in the call to the addThread() method and then restore that priority in the removeThread() method; we'll leave that implementation to the reader. [1]

Given this interface, we can use the CPUScheduler class in the ThreadTest class we introduced at the beginning of this section: class TestThread extends Thread { String id; public TestThread(String s) { id = s; } public void doCalc(int i) { } public void run() { int i; for (i = 0; i < 10; i++) { doCalc(i); System.out.println(id); } } }

page 125

Java Threads, 2nd edition

public class Test { public static void main(String args[]) { CPUScheduler c = new CPUScheduler(100); TestThread t1, t2, t3; t1 = new TestThread("Thread 1"); t2 = new TestThread("Thread 2"); t3 = new TestThread("Thread 3"); c.addThread(t1); c.addThread(t2); c.addThread(t3); t1.start(); t2.start(); t3.start(); c.start(); } }

When our program calls c.start(), the CPUScheduler's run() method gets called; it is this run() method that actually manipulates all the threads to create the timesliced, round-robin scheduling. At its base level, the logic for our scheduler is simple: it loops forever, going through all the threads in our circular list of threads and adjusting their priorities as it goes. In between, it sleeps for timeslice milliseconds. The current thread runs for that many milliseconds before the scheduler wakes up again and readjusts the thread's priority. When there are no threads left to schedule - which would happen if the programmer had called removeThread() on all the threads previously added - the CPUScheduler exits by returning from the run() method. Let's examine how the four threads in our program - threads t1, t2, t3, and the CPUScheduler thread - will behave now. After we call the c.start() method, the threads in the program are in this state: PRIORITY 2: PRIORITY 6:

t1 -> t2 -> t3 -> NULL CPUScheduler -> NULL

As the highest priority thread in the program, the CPUScheduler thread is the currently running thread. It starts executing the run() method, where the first thing it does is change the priority of thread t1 to 4: PRIORITY 2: PRIORITY 4: PRIORITY 6:

t2 -> t3 -> NULL t1 -> NULL CPUScheduler -> NULL

The CPUScheduler, still the currently running thread, now sleeps, placing it into the blocked state. This causes t1 to become the currently running thread: PRIORITY 2: PRIORITY 4: BLOCKED:

t2 -> t3 -> NULL t1 -> NULL CPUScheduler -> NULL

When the CPUScheduler thread wakes up, it changes the priority of t1 back to 2 and the priority of t2 to 4: PRIORITY 2: PRIORITY 4: PRIORITY 6:

t3 -> t1 -> NULL t2 -> NULL CPUScheduler -> NULL

And so the cycle continues. 7.2.2.1 Adjustment 1: Synchronizing data within the CPUScheduler Now that we have the base logic of the CPUScheduler written correctly, we need to make sure the CPUScheduler class is itself thread safe and that we haven't introduced any race conditions into the scheduler by having incorrectly synchronized data. We'll go through this process in a series of stages because the example illustrates the necessary steps that you must take in designing any class to work with multiple threads. At first glance, there don't appear to be any variables that need synchronization: the only instance variable that needs to be protected is the variable threads, and all changes to the threads variable occur via methods of the CircularList class that are already synchronized. But what would happen if you called the remove-Thread() method and removed the thread that the CPUScheduler has marked as the current thread? It would be an error for the CPUScheduler to change the priority of this thread once it has been removed from the threads list, so the removeThread() method must somehow inform the CPUScheduler that the current thread has been removed.

page 126

Java Threads, 2nd edition

This means that the variable current must become an instance variable so that both the run() and removeThread() methods can access it. We can then synchronize access to that variable. Here's the new CPUScheduler class: public class CPUScheduler extends Thread { ... private Thread current; public void removeThread(t) { t.setPriority(5); threads.delete(t); synchronized(this) { if (current == t) current = null; } } ... public void run() { ... try { Thread.sleep(timeslice); } catch (InterruptedException ie) {}; synchronized(this) { if (current != null) current.setPriority(2); } } }

Alternatively, we could make the run() and removeThread() methods themselves synchronized: public synchronized void run() { ... } public synchronized void removeThread(Thread t) { ... }

As we've seen, making the run() method synchronized is typically a bad idea, so we'll reject this idea for now, but we'll be revisiting this decision soon. 7.2.2.2 Adjustment 2: Making CPUScheduler thread safe We've synchronized all the variables of our CPUScheduler, but we're still not protected from threads that exit while they are under our control. In particular, the run() method changes the priority of a thread, which is a valid operation only if a thread is in the runnable state. What happens if the thread that we've assigned to level 4 exits its run() method while our CPUScheduler is sleeping? When the CPUScheduler wakes up, it tries to set the priority of that thread, which is now in the exiting state, to 2 - an operation that generates an exception. Similarly, if the thread that is running decides to call the stop() method of one of the priority 2 threads in the CPUScheduler's list, then the next time the CPUScheduler selects that thread and sets its priority, we'll get an exception. So we need to place all the calls to the setPriority() method inside a try/catch clause in order to be alerted to these types of situations. This means we must modify our code everywhere we call the setPriority() method: public void removeThread(Thread t) { try { t.setPriority(5); } catch(Exception e) {} threads.delete(t); synchronized(this) { if (current == t) current = null; } }

page 127

Java Threads, 2nd edition

public void run() { while (shouldRun) { ... try { current.setPriority(4); } catch (Exception e) { removeThread(current); } ... synchronized(this) { if (current != null) try { current.setPriority(2); } catch (Exception e) { removeThread(current); } } ... } }

Note that in in the run() method, when the exception is thrown we need to remove the thread from the list of threads we're interested in, which means that we must also use the catch clause in the removeThread() method. 7.2.2.3 Adjustment 3: More thread-safe modifications We've made the methods of the CPUScheduler thread-safe, but what about the class itself? What if two threads try to create a CPUScheduler? This would be very confusing: we'd end up with two scheduling threads that would compete with each other to schedule other threads. So we need to allow only one instance of the class to be instantiated. We'll do this by creating a static variable in the class and testing it to make sure that an instance of the CPUScheduler class doesn't already exist. Because we can't make the constructor itself synchronized, we'll also need to introduce a synchronized method to access this static variable. Thus the constructor and related code for the class now look like this: public class CPUScheduler extends Thread { private static boolean initialized = false; private synchronized static boolean isInitialized() { if (initialized) return true; initialized = true; return false; } public CPUScheduler(int t) { if (isInitialized()) throw new SecurityException("Already initialized"); threads = new CircularList(); timeslice = t; } }

7.2.2.4 Adjustment 4: Devising an exit mechanism If all the threads under its control exit, the CPUScheduler itself exits. In a program where the tasks are well defined at the beginning of execution - like the TestThread class we've looked at so far - that might be fine. But what if we wanted to add the CPUScheduler to our TCPServer? As presently written, the CPUScheduler wouldn't work for that case: as soon as no clients were connected to the TCPServer, the CPUScheduler would exit, and any further clients that connected to the server would not be timesliced. Instead, we need to make the CPUScheduler a daemon thread and adjust the logic of its run() method. This should make sense: the CPUScheduler is only useful when there are other threads in the program that it can schedule. In the TCP-Server case, there will always be at least one other thread in the program: the listener thread of the TCPServer. That listener thread creates other threads for the CPUScheduler to manipulate as clients connect to the server.

page 128

Java Threads, 2nd edition

The implementation of our timesliced TCPServer to perform calculations looks like this: import java.net.*; import java.io.*; public class CalcServer { public static void main(String args[]) { CalcRequest r = new CalcRequest(); try { r.startServer(3535); } catch (Exception e) { System.out.println("Unable to start server"); } } } class CalcRequest extends TCPServer { CPUScheduler scheduler; CalcRequest() { scheduler = new CPUScheduler(100); scheduler.start(); } void doCalc(Socket s) { } public void run(Socket s) { scheduler.addThread(Thread.currentThread()); doCalc(s); } }

Every time the run() method of the CalcRequest class is called, it is called in a new thread, so we need to add that thread to the CPUScheduler that was created in the constructor of the class. As long as the CPUScheduler doesn't exit when there are no threads to schedule (which now means simply that no client is currently connected), we'll have a timesliced calculation server. During an active session of our CalcServer, we'll have these threads: One listener thread The thread that waits for connections and creates the client threads. Zero or more client threads These threads execute the calculation on behalf of a connected client. CPUScheduler thread The daemon thread performing the scheduling. We can gracefully shut down the CalcServer by setting the shouldRun flag of the server to false; eventually the client threads complete their calculation and exit. When all the client threads have exited, only the daemon CPUScheduler thread remains in the program, and the program terminates. We need to change the CPUScheduler so that instead of returning when there are no threads to be scheduled, it simply waits for more threads. Here's the entire code for the modified CPUScheduler class (we'll show the entire class here, since at this point, we have a complete implementation): public class CPUScheduler extends Thread { private CircularList threads; private Thread current; private int timeslice; private static boolean initialized = false; private boolean needThreads; private static synchronized boolean isInitialized() { if (initialized) return true; initialized = true; return false; }

page 129

Java Threads, 2nd edition

public CPUScheduler(int t) { if (isInitialized()) throw new SecurityException("Already initialized"); threads = new CircularList(); timeslice = t; setDaemon(true); } public synchronized void addThread(Thread t) { t.setPriority(2); threads.insert(t); if (needThreads) { needThreads = false; notify(); } } public void removeThread(Thread t) { threads.delete(t); synchronized(this) { if (t == current) current = null; } } public synchronized void run() { setPriority(6); while (true) { current = (Thread) threads.getNext(); while (current == null) { needThreads = true; try { wait(); } catch (Exception e) {} current = (Thread) threads.getNext(); } try { current.setPriority(4); } catch (Exception e) { removeThread(current); continue; } try { wait(timeslice); } catch (InterruptedException ie) {}; if (current != null) { try { current.setPriority(2); } catch (Exception e) { removeThread(current); } } } } }

In the constructor, we've set the thread to be a daemon thread - the point of this adjustment. Note that we also changed the run() method so that when we try to retrieve a thread from the list, we loop until one is available. If no thread is in the list, we wait until one is available, which requires that we add a flag to the addThread() method to signify whether it should notify the CPUScheduler thread that a thread has been added. In addition, note that we've changed the run() method itself to a synchronized method and replaced the call to the sleep() method with a call to the wait() method. This is one example of the exception to the general rule that the run() method should not be synchronized: since we actually spend more time waiting in this method than executing code, its quite okay to synchronize the run() method, since it will release the lock whenever it waits for something to happen.

page 130

Java Threads, 2nd edition

7.2.2.5 Adjustment 5: Non-CPU-intensive threads What happens in our scheduler if the currently running thread blocks? Let's see what would happen to our TestThread program if the currently running thread suddenly entered the blocked state. We'd start out with the threads in a state like this: PRIORITY 2: PRIORITY 4: BLOCKED:

t3 -> t1 -> NULL t2 -> NULL CPUScheduler -> NULL

Thread t2 is the currently running thread, executing its calculations while the CPUScheduler is sleeping. If t2 now enters the blocked state for some reason, we end up with threads in this state: PRIORITY 2: PRIORITY 4: BLOCKED:

t3 -> t1 -> NULL NULL t2 -> CPUScheduler -> NULL

This means that t3 becomes the currently running thread, even though it's at priority 2. When the CPUScheduler wakes up, it resets the priority of t2 to 2, sets the priority of t3 to 4, and goes back to sleep, leaving our threads in this state: PRIORITY 2: PRIORITY 4: BLOCKED:

t1 -> NULL t3 -> NULL t2 -> CPUScheduler -> NULL

Everything is okay again, but at some point it will be t2's turn to be priority 4. Since the CPUScheduler has no way of determining that t2 is blocked, it sets the priority of t2 to 4. The Java scheduler again selects one of the threads at priority 2 to be the currently running thread. Our code was correct: the threads involved all got some timeslice in which to run. But there was a short period of time during which the CPUScheduler slept, the priority 4 thread blocked, and a priority 2 thread became the currently running thread. In effect, this priority 2 thread stole some CPU time; it could do this because there was a time gap between when the priority 4 thread blocked and the priority 6 thread woke up. It's probably not a crisis that this happened, since once the CPUScheduler woke up, we got back to the thread state we wanted. We could have prevented this CPU stealing from happening if somehow we knew when the priority 4 thread had blocked. However, on a native-thread platform, we cannot prevent a lower-priority thread from running at some point anyway, which is really just a variation of the behavior that we're discussing here. So solving this problem is not something that we'll be able to do in an absolute sense. It is conceivable that on a green-thread platform, we could create a new thread within the CPUScheduler class at priority 3. When the priority 4 thread blocks, this priority 3 thread would become the currently running thread; this priority 3 thread could inform the priority 6 thread that it should wake up and perform some scheduling. Note that on a native-thread platform this does not work: the priority 3 thread might still run even if the priority 4 thread has not blocked, and on a Windows platform, priority 3 and 4 share the same underlying operating system priority. Altering the priority levels of the threads to avoid this overlap - by, for example, running the scheduler at priority 8 and the target thread at priority 6 - is a possibility, but we've seen that putting a CPU-intensive thread above the default priority level (especially the level at which the system GUI thread runs) is not always a good idea. And this does not prevent the priority 3 thread from running when the target thread is not blocked. Even on a green-thread platform, this problem is impossible to solve in the general case. If all the threads to be scheduled were to block, then the priority 3 thread would continually run, consuming a lot of CPU resources but performing no real work. In the first edition of this book, we showed how to overcome that problem by suspending the priority 3 thread, but now the suspend() method has been deprecated, so that solution is no longer an option. And since the benefit provided by such a solution would be very marginal, we're not too worried that such a solution does not exist. The moral of the story is what we've said all along: Java's scheduling mechanisms give you some control over how threads are scheduled, but that control is never absolute.

page 131

Java Threads, 2nd edition

7.3 Job Scheduling We'll conclude our examples with an examination of job scheduling. Unlike round-robin scheduling, job scheduling is not related to thread starvation prevention or fairness. The concept of job scheduling is more closely related to when a runnable object is executed than to how a runnable object is run. There are many applications of job scheduling. We could have a word processor application that needs to save work every five minutes to prevent data loss. We could have a backup program that needs to do an incremental backup every day; this same program may also need to do a full backup once a week. In our Animate applet (see Chapter 2), we needed to generate a repaint request every second. At the time, we accomplished that by having the timer thread schedule itself by calling the sleep() method repeatedly. In that example, the scheduling of the repaint request was simple to implement, and we only had this single repeated job to schedule. For more complex scheduling of jobs, or for programs that have countless jobs that need to be scheduled, having a dedicated job scheduler may be easier than implementing the scheduling of every job in the program. Furthermore, in the case of the timer thread, we needed to create a thread just to handle the job. If many jobs are required, a job scheduler may be preferred over having many threads that schedule themselves. This dedicated job scheduler can run all the jobs in its own thread, or it can assign the jobs to a thread pool to better use the thread resources of the underlying platform. Here's an implementation of a job scheduler class: import java.util.*; public class JobScheduler implements Runnable { final public static int ONCE = 1; final public static int FOREVER = -1; final public static long HOURLY = (long)60*60*1000; final public static long DAILY = 24*HOURLY; final public static long WEEKLY = 7*DAILY; final public static long MONTHLY = -1; final public static long YEARLY = -2; private class JobNode { public Runnable job; public Date executeAt; public long interval; public int count; } private ThreadPool tp; private DaemonLock dlock = new DaemonLock(); private Vector jobs = new Vector(100); public JobScheduler(int poolSize) { tp = (poolSize > 0) ? new ThreadPool(poolSize) : null; Thread js = new Thread(this); js.setDaemon(true); js.start(); } private synchronized void addJob(JobNode job) { dlock.acquire(); jobs.addElement(job); notify(); } private synchronized void deleteJob(Runnable job) { for (int i=0; i < jobs.size(); i++) { if (((JobNode) jobs.elementAt(i)).job == job) { jobs.removeElementAt(i); dlock.release(); break; } } }

page 132

Java Threads, 2nd edition

private JobNode updateJobNode(JobNode jn) { Calendar cal = Calendar.getInstance(); cal.setTime(jn.executeAt); if (jn.interval == MONTHLY) { // There is a minor bug (see java.util.calendar). cal.add(Calendar.MONTH, 1); jn.executeAt = cal.getTime(); } else if (jn.interval == YEARLY) { cal.add(Calendar.YEAR, 1); jn.executeAt = cal.getTime(); } else { jn.executeAt = new Date(jn.executeAt.getTime() + jn.interval); } jn.count = (jn.count == FOREVER) ? FOREVER : jn.count - 1; return (jn.count != 0) ? jn : null; } private synchronized long runJobs() { long minDiff = Long.MAX_VALUE; long now = System.currentTimeMillis(); for (int i=0; i < jobs.size();) { JobNode jn = (JobNode) jobs.elementAt(i); if (jn.executeAt.getTime() firstWriter()) { try { wait(); } catch (Exception e) {} } node.nAcquires++; } public synchronized void lockWrite() { RWNode node; Thread me = Thread.currentThread(); int index = getIndex(me); if (index == -1) { node = new RWNode(me, RWNode.WRITER); waiters.addElement(node); } else { node = (RWNode) waiters.elementAt(index); if (node.state == RWNode.READER) throw new IllegalArgumentException("Upgrade lock"); node.state = RWNode.WRITER; } while (getIndex(me) != 0) { try { wait(); } catch (Exception e) {} } node.nAcquires++; } public synchronized void unlock() { RWNode node; Thread me = Thread.currentThread(); int index; index = getIndex(me); if (index > firstWriter()) throw new IllegalArgumentException("Lock not held"); node = (RWNode) waiters.elementAt(index); node.nAcquires--; if (node.nAcquires == 0) { waiters.removeElementAt(index); notifyAll(); } } }

The interface to the reader-writer lock is very simple: there's a method lockRead() to acquire the read lock, a method lockWrite() to acquire the write lock, and a method unlock() to release the lock (only a single unlock() method is required, for reasons we'll explore in a moment). Just as in our QueuedBusyFlag class, threads attempting to acquire the lock are held in the waiters vector until they are first in line for the lock, but the definition of first in line has changed somewhat.

page 150

Java Threads, 2nd edition

A Reader-Writer Lock Is a Single Lock You might be tempted to think of the reader-writer lock as two separate but related locks: a lock to read and a lock to write. You might be led to think this because of our vocabulary: we consistently refer to a reader lock and a writer lock as if there were two separate locks involved in this process. On a logical level, that's true, and we'll continue to use that vocabulary, but we're actually implementing a single lock.

Because we need to keep track of how each thread wants to acquire the lock - whether it wants to acquire the read lock or the write lock - we need to create a class to encapsulate the information of the thread that made the request and the type of request it made. This is the RWNode class; our waiters queue now holds elements of type RWNode instead of the Thread elements that were present in the QueuedBusyFlag class. The acquisition of the read lock is the same as the logic of the QueuedBusyFlag class except for the new definition of first in line. First in line for the read lock means that no other node ahead of us in the waiters queue wants to acquire the write lock. If the nodes that are ahead of us in the waiters queue want only to acquire the read lock, then we can go ahead and acquire the lock. Otherwise, we must wait until we are in position zero. The acquisition of the write lock is stricter: we must be in position for the lock in order to acquire it, just as was required in our QueuedBusyFlag class. The logic to keep track of the number of times a particular thread has acquired a lock has undergone a slight change. In the QueuedBusyFlag class, we were able to keep track of this number as a single instance variable. Since the read lock can be acquired by multiple threads simultaneously, we can no longer use a simple instance variable; we must associate the nAcquires count with each particular thread. This explains the new logic in both acquisition methods that checks to see if there is already a node associated with the calling thread. Our reader-writer lock class does not have the notion of "upgrading" a lock; that is, if you hold the reader lock, you cannot acquire the writer lock. You must explicitly release the reader lock before you attempt to acquire the writer lock, or you will receive an IllegalArgumentException. If an upgrade feature were provided, the class itself would also have to release the reader lock before acquiring the writer lock. A true upgrade is not possible. Finally, our reader-writer lock class contains some helper methods to search the waiters queue for the first node in the queue that represents a thread attempting to acquire the write lock (firstWriter()) and to find the index in the queue of the node associated with the calling thread (getIndex()). We can't use the Vector class indexOf() method for this purpose because we'd have to pass the indexOf() method an object of type RWNode, but all we have is a thread. Figure 8.3 shows the state of the waiters queue through several attempts at lock acquisition. Threads that have acquired the lock have a white background, whereas threads that are waiting to acquire the lock have a shaded background; each box notes whether the thread in question is attempting to acquire the read or the write lock. At point 1, thread T1 has acquired the read lock. Since it is the only thread in the waiters queue, the getIndex() method returns while the firstWriter() method returns MAX_VALUE. Since the index

was less than the first writer, the lock is granted. At point 2, thread T2 has requested (and been granted) the read lock based on the same logic. Here's a point at which two threads simultaneously have the read lock.

At point 3, thread T3 attempts to acquire the write lock. Because the index of T3 in the queue is 2, it cannot grab the lock and instead executes the wait() method inside the lockWrite() method. Then at point 4, thread T1 releases the read lock. The unlock() method calls notifyAll(), which wakes up T3, but because T3's index in the queue is now 1, it again executes the wait() method.

page 151

Java Threads, 2nd edition

Figure 8.3. Reader-writer lock queue

At point 5, thread T1 again attempts to acquire the read lock, but this time, because its index in the queue (2) is greater than the index of the first writer (1), it does not immediately get the lock and instead executes the wait() method inside the lockRead() method. We might be tempted at this point to allow T1 to acquire the read lock since T2 already has the read lock and we generally allow multiple simultaneous acquisitions of the read lock. But if we implement that logic, we will starve the threads attempting to acquire the write lock: we could have multiple threads acquiring the read lock, and even though they might individually give up the lock frequently, one of them could always prevent a thread from acquiring the write lock. That's the rationale for always putting the requesting thread into the waiters queue and then testing its index against other threads in the queue, as happens again at point 6. At point 7, thread T2 releases the read lock, notifying all other threads that the lock is free. Because T3 is a writer lock with an index of 0, the lockWrite() method gives it the lock while the other threads in the lockRead() method execute wait(). Finally, at point 8, thread T3 releases the lock. This time when the two remaining threads are notified that the lock is free, they are both able to acquire it, as their indices are less than MAX_VALUE (the integer returned when there are no threads attempting to acquire the write lock). Once again we have multiple threads that have simultaneous access to the read lock. This is also a case where the notifyAll() method makes it easy to wake up multiple threads at once.

8.3.2 Priority-Inverting Locks The last example that we'll look at in this section is the starvation that is associated with priority inversion. On the virtual machines that we've looked at, priority inversion is solved by priority inheritance. But what if we need to use the BusyFlag class to lock at a large scope in our program? How does priority inheritance affect our BusyFlag class? Not surprisingly, it does not have any affect on the behavior of this class, because we are only simulating a lock, and are using Java's synchronization locks only to protect against the race conditions that occur within this task. Once a BusyFlag is acquired and the getBusyFlag() method exits, the synchronization lock protecting the getBusyFlag() method is released. As far as the Java virtual machine is concerned, no synchronization locks are held at this point. A low-priority thread that holds a BusyFlag will never have its priority adjusted by the virtual machine if a high-priority flag attempts to acquire the same BusyFlag: because they never attempt to execute the same synchronized method at the same time, the virtual machine is unaware that they are competing with each other at all.

page 152

Java Threads, 2nd edition

We can easily implement a version of the BusyFlag class that has support for priority inheritance: public class PriorityBusyFlag extends BusyFlag { protected int currentPriority; public synchronized void getBusyFlag() { while (tryGetBusyFlag() == false) { Thread prevOwner = getBusyFlagOwner(); try { int curP = Thread.currentThread().getPriority(); if (curP > prevOwner.getPriority()) { prevOwner.setPriority(curP); } wait(); } catch (Exception e) {} } } public synchronized boolean tryGetBusyFlag() { boolean succeed = super.tryGetBusyFlag(); if (succeed) currentPriority = Thread.currentThread().getPriority(); return succeed; } public synchronized void freeBusyFlag() { if (getBusyFlagOwner() == Thread.currentThread()) { super.freeBusyFlag(); if (getBusyFlagOwner() == null) { Thread.currentThread().setPriority(currentPriority); notifyAll(); } } } }

Usage of the PriorityBusyFlag class is similar to usage of the BusyFlag class. The two differences are that the requesting thread will raise the priority of the thread that already owns the BusyFlag if the priority of the requesting thread is higher than the priority of the owning thread, and the original priority of the thread will be restored when the BusyFlag is freed. This behavior is functionally identical to native-threading systems that support priority inheritance. However, in a virtual machine, these details are handled internally. The best that we can do is to use the PriorityBusyFlag class in a cooperative manner by using the setPriority() method. If another thread also changes the priority of threads, or the threads themselves are changing their priority, this cooperative technique will not work.

8.4 Thread-Unsafe Classes In a perfect world, we would not have to write this section: in that world, every class that you used would be correctly synchronized for use by multiple threads running simultaneously, and you would be free from considering synchronization issues whenever you used someone else's Java classes. Welcome to the real world. In this world, there are often times when you need to use classes that are thread unsafe - classes that lack the correct synchronization to be used by multiple threads. Just because we acknowledge that these circumstances exist does not mean that you are absolved from producing thread-safe classes in your own work: we urge you to make this a better world and correctly synchronize all of your own classes. In this section, we'll examine two techniques that allow you to deal with classes that are not thread safe.

8.4.1 Explicit Synchronization Since its inception, Java has had certain classes that are collection classes: the Hashtable class, the Vector class, and others provide aggregates of objects. These classes all have the advantage that they are thread safe: their methods contain the necessary synchronization such that two threads that simultaneously insert objects into a vector, for example, will do so without corrupting the internal state of the vector.

page 153

Java Threads, 2nd edition

Java 2 formalized the notion of a collection by introducing a number of collection classes; these are classes that implement either the Collection or the Map interface. There are a number of these classes: the HashMap and ArrayList classes, for example, provide similar semantics to the original Hashtable and Vector classes. But there is a big difference: most of the new collection classes are not thread safe. In fact, there is no rule about these classes: while most of them are not thread safe, some of them are (such as the original Hashtable class, which implements the Map interface). And most of the threadunsafe classes have the capability of providing a thread-safe implementation, so that when you deal with an object that is only identified by a generic type (such as Map), you are unsure as to whether the object in question is thread safe.

Synchronized Collections As an aside, we'll mention that the Collection class has several methods synchronizedCollection(), synchronizedMap(), synchronizedList(), and synchronizedSet() - that turn a thread-unsafe collection object into a thread-safe collection object. The techniques that we're discussing here apply only to the unsafe versions of collections; we're really just using the collection classes to illustrate our larger point.

This all places a big burden on the developer, who must now figure out whether a particular Map object is thread safe, and, if not, must then ensure that the object is used correctly when multiple threads are present. The easiest way to do this is simply to explicitly synchronize all access to the object: import java.util.*; public class ArrayTest { private ArrayList al; public ArrayTest() { al = new ArrayList(); } public void addItems(Object first, Object second) { synchronized(al) { al.add(first); al.add(second); } } public Object get(int index) { synchronized(al) { return al.get(index); } } }

All accesses to the array list in this example are synchronized; now multiple threads can call the addItems() and get() methods of the ArrayTest without damaging the internal state of the array list. Note that we've made the array list itself private. In order for this technique to work, we have to ensure that no one inadvertently uses the array list without synchronizing it, and the simplest way to do that is to hide the actual array list within the object that uses it. That way, we only have to worry about accesses to the array list from within our ArrayTest class. The addItems() method shows one advantage of providing the collection classes as they are: we can add multiple items to the collection within a single synchronization block. This is more efficient than synchronizing the add() method of the ArrayList class. In our test class, we need only obtain the synchronization lock once; in the traditional Vector class, we'd have to obtain the synchronization lock twice. This efficiency comes at a high price, however: if you forget to synchronize the map correctly, you'll end up with a nasty race condition that will be very hard to track down. Which side you land on in this debate is a matter of personal preference.

page 154

Java Threads, 2nd edition

This technique can be used with any thread-unsafe class provided that all accesses to the threadunsafe objects are synchronized as we've shown. There are some thread-unsafe classes (such as the JFC [Swing] classes, which we'll look at later) for which this technique will not work, since those classes internally call other thread-unsafe classes and do not synchronize access internally to those unsafe objects. But for unsafe data structure classes, explicit synchronization is the technique to use. 8.4.1.1 Explicit synchronization and native code You must use explicit synchronization when you need to call a native library that is not thread safe. This may be a frequent occurrence, since developers who use C or other programming languages often do not consider that their libraries may be used in a threaded environment. However, there is a slight difference in this case. We cannot simply synchronize at the object level (as we did in the previous example), because every object is sharing the same native code: there is only one instance of the shared native library that is loaded into the virtual machine. Hence, we must synchronize at the class level, so that every object that uses the native library will share the same lock. It's simple to perform this task: public class AccessNative { static { System.loadLibrary("myLibrary"); } public static synchronized native void function1(); public static synchronized native void function2(); ... }

Here we simply make each method that calls into the native library both static and synchronized. This ensures that only one thread in the virtual machine can enter the native methods at any point in time, since they all would have to acquire the single lock associated with the AccessNative class. There is one caveat here: if another class also loads the myLibrary library, threads executing objects of that class will be able to call into the same native library code concurrent with the threads executing methods of the AccessNative class. This technique is similar to one that was used by the JDBC-ODBC bridge: in early versions of the bridge, it was assumed that the underlying ODBC drivers were not thread safe, and so the bridge serialized access to the native library. This greatly reduced the utility of the bridge, however, since threads could not concurrently access the database - which is a problem for most database applications, where threads that access the database are often blocked waiting for I/O. In Java 2, versions of the JDBC-ODBC bridge now assume that the underlying ODBC driver is thread safe. If you have a thread-unsafe ODBC driver, it is your responsibility to make sure that access to the driver is synchronized correctly. This is easily achieved using a modification of the first technique that we examined: simply make sure that any access to the Connection object of the driver is synchronized. In this case, however, since you are dealing with native code, you must also ensure that only one Connection object that uses the ODBC driver is present within the virtual machine.

8.4.2 Single-Thread Access The other technique to use with thread-unsafe classes is to ensure that only one thread ever accesses those classes. This is generally a harder task, but it has the advantage that it always works, no matter what those classes might do internally. This technique must be used whenever threads are present in a program that uses the Java Foundation Classes for its GUI. We'll first show you how to interact with the JFC specifically, and then generalize how that technique might be used with other classes (particularly with classes that you develop).

page 155

Java Threads, 2nd edition

8.4.2.1 Using the Java Foundation Classes The Java Foundation Classes are the largest set of classes in the Java platform, and they also bear the distinction of being one of the few sets of classes that are not thread safe. Hence, whenever these classes are used, we must take care that we access JFC objects only from one thread; in particular, we must ensure that we access JFC objects only from the event-dispatching thread of the virtual machine. This is the thread that executes any of the listener methods (such as actionPerformed()) in response to events from the user. All JFC objects are thread unsafe, which means that if we have our own thread that wants to invoke a method on such an object, it cannot do so directly. A thread that attempts to read the value of a slider, for example, cannot do so directly, since as it is reading the value of the slider, the user might be simultaneously changing the value of the slider. Since access to the slider is not synchronized, both threads might access the internal slider code at the same time, corrupting the internal state of the slider and causing an error. Hence, our own thread must arrange for the event-dispatching thread of the virtual machine to read the value of the slider and pass that data back to the thread. This example also illustrates why the previous technique of explicitly synchronizing access to objects will not work for JFC: our thread could synchronize access to the slider, but the event-processing thread does not synchronize its internal access. Remember that locks are cooperative; if all threads do not attempt to acquire the lock, then race conditions can still occur. So the requirement to interact safely with Swing components is to access them only from the eventdispatching thread; since that effectively makes access to those components single-threaded, there will be no race conditions. JFC contains many methods that are executed by the event-dispatching thread: •

Methods of the listener interfaces in the java.awt.event package when those methods are called from the event-dispatching thread

•

invokeAndWait()

•

invokeLater()

•

repaint()

We'll look at each of these in turn. 8.4.2.2 The event-dispatching thread and event-related method First, let's delve into what we mean by the event-dispatching thread. When the Java virtual machine begins execution, it starts an initial thread. Later, when the first AWT-related class (including a JFC class) is instantiated, the GUI toolkit inside of the JVM is initialized. Depending on the underlying operating system, this creates one or more additional threads that are responsible for interacting with the native windowing system. Regardless of the number of threads created, one of these threads is known as the event-dispatching thread. This thread is responsible for getting events from the user; when the user types a character, the event-dispatcher thread receives this event from the underlying windowing system. When the user moves the mouse or presses a mouse button, the event-dispatching thread receives that event as well. When it receives an event, it begins the process of dispatching that event: it figures out which AWT component the event occurred on and calls the event methods that are registered on that component. So any method that is called in response to one of these events will be called in the event-dispatching thread. In normal circumstances, any of the event-related methods - actionPerformed(), focusGained(), itemStateChanged(), and any other method that is part of one of the listener interfaces in the java.awt.event package - will be called by the event-dispatching thread.

page 156

Java Threads, 2nd edition

That's good news, since it means that most of the code that needs to access Swing components will already be called in the event-dispatching thread. So for most GUI code, you do not need to use one of the other methods in our list: you only need to use the invokeAndWait() or invokeLater() methods if you want to access Swing components from a thread other than the event-dispatching thread. In other words, if you add your own thread to a Swing-based program and that additional thread directly accesses a Swing component, you need to use either the invokeAndWait() or invokeLater() methods. Otherwise, you just write your event-related methods as you normally would. There are two subtle points to make about event dispatching. The first is that methods of the JApplet class that seem to be event-related are not called in the event-dispatching thread. In particular, the start() and stop() methods of the JApplet class are called by another thread in the program, and you should not directly access any Swing components in these methods. This warning technically applies to the init() method as well. Since the init() method typically does make Swing calls (e.g., to the add() method), that might seem like an ominous development. However, browsers are responsible for calling the init() method only once, and for calling it in a manner in which the Swing classes can be used safely. If you write your own application that uses an instance of a JApplet within it, you must take care to do the same thing: do not call the show() method of any JFrame before you call the init() method of the JApplet class (or use the invokeAndWait() method to ensure that the init() method is itself run in the event-dispatching thread). And, of course, if your program calls the init() method, it should take care to ensure that it does so from the event-dispatching thread. The second point is more complicated, and it stems from the fact that it is possible to call an eventrelated method from a thread other than the event-dispatching thread. Let's say that you have a thread in which a socket is reading data from a data feed; the socket gets an I/O error, and now you want to shut down the program. You might be tempted in this case to call the same actionPerformed() method that is called in response to the user selecting the button labeled "Close" - after all, that method has the necessary logic to shut the program down, and you wouldn't want to rewrite that logic. So in this case, the actionPerformed() method can be called by two different threads: the event-dispatching thread (in response to a user event) and the socket-reading thread (in response to an I/O error). To accommodate both threads, you must make access to any Swing components in the actionPerformed() method safe by using one of the invoke methods that we'll discuss next. The point is that there's nothing inherent within the actionPerformed() method (or any other eventrelated method) that makes it safe to manipulate Swing components: either the method is being executed by the event-dispatching thread itself (safe), or it is being executed by another thread (not safe). The thread context determines whether or not it is safe to directly manipulate a Swing component, not the method itself.

Which invokeAndWait() Method? In Java 2, the EventQueue class introduces three new static methods: isEventDispatchThread(), invokeLater(), and invokeAndWait(). These methods are functionally identical to their counterparts in the SwingUtilities class. You may use either one depending upon your preference; using the methods of the SwingUtilities class will keep your program compatible with Java 1.1.

8.4.2.3 The invokeAndWait() method The easiest way to ensure that access to Swing components occurs in the event-dispatching thread is to use the invokeAndWait() method. When a thread executes the invokeAndWait() method, it asks the event-dispatching thread to execute certain code, and the thread blocks until that code has been executed.

page 157

Java Threads, 2nd edition

Let's see an example of this. The invokeAndWait() method is often used when a thread needs to get the value of certain items within the GUI. In the following code, we use the invokeAndWait() method to get the value of the slider: import javax.swing.*; import java.awt.*; public class SwingTest extends JApplet { JSlider slider; int val; class SwingCalcThread extends Thread { public void run() { Runnable getVal = new Runnable() { public void run() { val = slider.getValue(); } }; for (int i = 0; i < 10; i++) { try { Thread.sleep(2000); SwingUtilities.invokeAndWait(getVal); System.out.println("Value is " + val); } catch (Exception e) {} } } } public void init() { slider = new JSlider(); getContentPane().setLayout(new BorderLayout()); getContentPane().add("North", slider); } public void start() { new SwingCalcThread().start(); } }

While simply the skeleton of a real program, this applet puts up a slider and then starts a secondary thread to perform a calculation. Let's look at how execution of this applet will proceed: 1.

The applet will initialize itself (via the init() method), creating a GUI with a single element (a slider).

2. In the applet's start() method, a calculation thread is spawned. 3. The calculation thread will then begin executing (okay, it's just sleeping, but it could be doing something useful here). Periodically, the calculation thread needs to obtain the current setting of the slider. It does this by creating a runnable object (the getVal instance variable) and passing that object to the invokeAndWait() method. The calculation thread then blocks until the invokeAndWait() method returns. 4. Meanwhile, the invokeAndWait() method itself has arranged for the run() method of the get object to be invoked in the event-dispatching thread of the GUI. When that run() method is invoked, the value of the slider is stored into the val instance variable. 5.

Once the run() method of the getVal object has returned, the invokeAndWait() method will return and the calculation thread can continue its next iteration.

There's a further complication here, however: you cannot call the invokeAndWait() method from the event-dispatching thread itself; doing so will cause an error to be thrown. If you want to execute the same code from an event callback method and from a user thread - e.g., the socket example we described a little earlier - then you cannot simply put all references to Swing components inside of a call to the invokeAndWait() method in the actionPerformed() method; you must instead use the SwingUtilities.isEventDispatchThread() method to see if you're in the event dispatch method and code the actionPerformed() method accordingly.

page 158

Java Threads, 2nd edition

A skeleton of this example would look like this: public class TestSwing extends JApplet implements ActionListener { class ReaderThread extends Thread { public void run() { try { //... read the socket, process the data ... } catch (IOException ioe) { actionPerformed(null); } } } public void init() { JButton jb = new JButton("Close"); getContentPane().add(jb); jb.addActionListener(this); } public void actionPerformed(ActionEvent ae) { class doClose implements Runnable { public void run() { //... access Swing components here ... //... This code would normally be the body ... //... of the actionPerformed method ... } }; doClose dc = new doClose(); if (SwingUtilities.isEventDispatchThread()) dc.run(); else { try { SwingUtilities.invokeAndWait(dc); } catch (Exception e) {} } } }

This restriction does not apply to the invokeLater() method. 8.4.2.4 The invokeLater() method The invokeLater() method is similar to the invokeAndWait() method except that it does not block. Because it does not wait for the target object's run() method to complete, this method is inappropriate for those instances when you need to retrieve data from JFC objects. However, this method can be used to set data within a JFC object: import javax.swing.*; import java.awt.*; public class SwingTest extends JApplet { JSlider slider; JLabel label; int val; class SwingCalcThread extends Thread { public void run() { Runnable getVal = new Runnable() { public void run() { val = slider.getValue(); } }; Runnable setVal = new Runnable() { public void run() { label.setText("Last calc is " + val); } }; for (int i = 0; i < 10; i++) { try { Thread.sleep(2000); SwingUtilities.invokeAndWait(getVal); SwingUtilities.invokeLater(setVal); } catch (Exception e) {} } } }

page 159

Java Threads, 2nd edition

public void init() { slider = new JSlider(); label = new JLabel("Last calc is 0"); getContentPane().setLayout(new BorderLayout()); getContentPane().add("North", slider); getContentPane().add("Center", label); } public void start() { new SwingCalcThread().start(); } }

In this case, there's no reason why the calculation thread needs to wait until the data in the label is actually set; it merely schedules the operation and then continues to calculate. There are circumstances in which this is inappropriate. In this example, the new value of the label will not be reflected immediately when the invokeLater() method is called. As a result, the threads may be scheduled such that one iteration of the intermediate feedback is lost to the user. But in general, the invokeLater() method is useful when the thread that invokes it does not care about the results of the run() method. 8.4.2.5 The repaint() method The repaint() method is also a thread-safe method, even within the JFC. Hence, any thread can at any time call the repaint() method of a particular component. This is very useful, since a variety of Java applications depend on periodic repainting behavior. The reason this works is that the repaint() method itself doesn't really accomplish a great deal: it merely arranges for the paint() method to be called by the event-dispatching thread. Hence, an applet can have a thread that stores data into the instance variables of the applet and then calls the applet's repaint() method; when the applet next paints itself, it will use the new data. There are other techniques for dealing with threads and the JFC. There is a timer class within the JFC that hides the details of the invokeLater() method for you; you pass an ActionListener object to the timer and it arranges for the actionPerformed() method of that object to be called from the eventdispatching thread every time the timer fires. Additionally, there is a SwingWorker class on Sun's web site that performs the opposite of the principles that we've shown here: it dispatches a new target thread and provides a way for code within the event-dispatching thread to poll the target thread for its results. In our opinion, this is backwards: how will the event-dispatching thread know when it should check for output from the worker thread? Still, if you're interested, check out Sun's web site for more details. How unsafe are the Swing classes, anyway? In the examples we've just shown, we've essentially set and retrieved an integer - the value - from the JSlider class. Since reading or writing an integer is guaranteed to be an atomic action in Java, is it really necessary to use the invoke methods? There are probably cases where the answer is no, but those cases cannot be clearly described. So it's really safer to use the invoke methods to execute all Swing methods from a thread other than the eventdispatching thread. Even in our example where we seem to be performing a simple assignment, there's a lot going on that we're not aware of: the getValue() method has to call the getModel() method, and a new model may be in the middle of being installed. That may be okay, or it may cause the getModel() method to return a null object reference, which would cause a runtime exception; without a very careful examination of the Swing code, it's tough to be sure. And it's impossible to know what future implementations might be. It's far better just to use the invoke methods as we've shown. 8.4.2.6 Other thread-unsafe classes The implementation of the invokeAndWait() method (as well as the other similar methods we've just examined) provides us with a clue on how to deal with other unsafe classes for which simple external synchronization is insufficient. We need to implement a similar mechanism for these classes.

page 160

Java Threads, 2nd edition

This is typically done by establishing a queue somewhere that one thread - and only one thread - is responsible for acting on. The invokeAndWait() method itself is based on the fact that there is an existing event queue within the virtual machine: it simply creates some new events, posts them to the queue, and waits for the event-dispatching thread to process them (the invokeLater() method returns without waiting). The event-dispatching thread is then responsible for executing the run() method of the object passed to the invokeAndWait() method. Interestingly enough, the invokeAndWait() method does not create a new thread, nor does it cause one to be created: the run() method is executed by an existing thread (the event-dispatching thread), just as we did in Chapter 7 with our thread pool example. This similarity tells us how to ensure that only a single thread accesses our unsafe classes: place all access to those classes within objects executing in a thread pool and initialize the thread pool to contain only a single thread. Now we can use the addRequest() and addRequestAndWait() methods of the thread pool just as we used the invokeLater() and invokeAndWait() methods earlier.

8.5 Summary The strong integration of locks into the Java language and API is very useful for programming with Java threads. Nonetheless, despite their strength, Java's locking mechanisms are not suitable for every type of synchronization you might need for more complex Java programs. Fortunately, the built-in synchronization techniques provide good building blocks to create the more complicated, more intelligent locks you need in special situations. Like other parts of Java, its built-in locking mechanism is designed to be simple in order to reduce errors in your Java programs. And, like other parts of Java, this simplicity is enough to carry you through all but the most complex programming situations. You should use the built-in techniques unless you really need the more complex behavior of the mechanisms described in this chapter. Finally, for those times when you are faced with other code that is not thread safe, Java's locking facilities offer the ability to use that code safely within a multithreaded program, either by explicitly locking such code or by ensuring that such code is only ever executed within a single thread.

page 161

Java Threads, 2nd edition

Chapter 9. Parallelizing for Multiprocessor Machines So far in this book, we've examined threading as a programming technique that allows us to simplify programming: we have used threading to achieve asynchronous behavior or to perform independent tasks. Although we discussed how threads are scheduled on machines with multiple processors, by and large the techniques that we've shown so far are not affected by a machine with multiple processors, nor do they exploit the number of processors on a machine to make the program run faster. Multithreaded applications have a special bond with multiprocessor systems. The separation of threads provides a clear and simple separation for the multiprocessor machine. Since the operating system can place different threads on different processors, the application will run faster. In this chapter, we'll look at how to parallelize Java programs so that they will run faster on a machine with multiple CPUs. The processes that we'll examine are beneficial not only to newly developed Java programs, but also to existing Java programs that have a CPU-intensive loop, allowing us to improve the performance of those programs on a multiprocessor system. How does the Java threading system behave in a multiprocessor system? There are no conceptual differences between a program running on a machine with one processor and a machine with two or more processors; the threads behave exactly the same in either case. However, as we discussed in Chapter 6, the key difference between a multiprocessor and a single-processor system is that there may be one currently running thread for each CPU on the host platform. The impact of this is that when our Java program runs on a machine with multiple processors, the following assumptions become very important: •

We can no longer assume that a currently running thread has the highest priority. A higherpriority thread may be running on a different processor.

•

We can no longer assume that a low-priority thread will not run. There may be enough processors to give it execution time.

•

We can no longer assume that threads of different priorities will not be running at the same time.

•

We can no longer assume that certain race conditions can be ignored because it is "unreasonable" for a particular case to occur. Race conditions in a multiprocessor system are real, whereas race conditions in a single-processor system are more dependent on the scheduling engine of the Java virtual machine.

The point to understand here is that these assumptions were never guaranteed in the first place. However, on a single-processor machine (especially under the green-thread model), violation of these assumptions was rare. On a multiprocessor system, these assumptions are violated quite often.

9.1 Parallelizing a Single-Threaded Program Without redesigning a program, the best area to parallelize - that is, the area in which to introduce multiple threads to increase the program's performance - is where the application is CPU bound. After all, there is no reason to bring in more processors if the first processor cannot stay busy. In many of the cases where the process is CPU bound - that is, the process is using all of the computer processors' cycles, while not using the disks or the network at full capacity - the speed of the application can increase with the addition of more processors. The process could be involved in a long mathematical calculation or, more likely, in large iterations of shorter mathematical calculations. Furthermore, these calculations probably involve a large control loop or even a large number of loops inside loops.

page 162

Java Threads, 2nd edition

These are the types of common algorithms that we will examine here. Consider the following calculation: public class SinTable { private float lookupValues[] = null; public synchronized float[] getValues() { if (lookupValues == null) { lookupValues = new float [360 * 100]; for (int i = 0; i < (360*100); i++) { float sinValue = (float)Math.sin( (i % 360)*Math.PI/180.0); lookupValues[i] = sinValue * (float)i / 180.0f; } } return lookupValues; } }

We'll use this code as the basis of our example for the rest of this chapter. A single thread, and hence a single processor, will execute the loop as specified in the code and store the results in the lookupValues array. Assuming that the calculation of the sinValue variable is time-consuming, the whole loop may take a long time to execute. For some cases, this is acceptable. However, on a twelveprocessor computer without any other application running, only one CPU will be working while the other eleven would be sitting idle. Considering the cost of a twelve-way machine, this is not acceptable. Before we get started, let's define some terminology.[1] The variable sinValue has a few special properties. Obviously, it exists only during the duration of the loop. It is a temporary variable used to aid the calculation of the lookup table. It does not carry a value in one iteration of the loop that is used in another iteration of the loop, and the value of the variable is reassigned in the next iteration. We will define sinValue as a loop-private variable, that is, a variable that is initialized, calculated, and used entirely in a single iteration of the loop. The terminology that we will be using in this section is somewhat based on the autothreading MP C compiler available for the Solaris operating system. [1]

Examining further, we can state that the index variable i is also a loop-private variable: it is also used completely in an iteration of the loop. It can be considered as a special type of loop-private variable. Since it is never changed in the iteration and is directly tied to the iteration index, we can actually treat it as a constant during the iteration of a loop. However, for now, simply considering it as a loopprivate variable is good enough. We may try to break the parts of this loop among many threads as follows: public class SinTable implements Runnable { private class SinTableRange { public int start, end; } private float lookupValues[]; private Thread lookupThreads[]; private int startLoop, endLoop, curLoop, numThreads; public SinTable() { lookupValues = new float [360 * 100]; lookupThreads = new Thread[12]; startLoop = curLoop = 0; endLoop = (360 * 100); numThreads = 12; } private synchronized SinTableRange loopGetRange() { if (curLoop >= endLoop) return null; SinTableRange ret = new SinTableRange(); ret.start = curLoop; curLoop += (endLoop-startLoop)/numThreads+1; ret.end = (curLoop= endLoop) return null; LoopRange ret = new LoopRange(); ret.start = curLoop; curLoop += groupSize; ret.end = (curLoop= endLoop) return null; LoopRange ret = new LoopRange(); ret.start = curLoop; int sizeLoop = (endLoop-curLoop)/numThreads; curLoop += (sizeLoop>minSize)?sizeLoop:minSize; ret.end = (curLoop