Achieve strong performance with threads, Part 1
Users expect programs to exhibit strong performance. To satisfy those expectations, your programs often use threads. This article begins a four-part series that examines threads. You receive an introduction to threads, explore the Thread class, and learn about runnables. Furthermore, the accompanying sidebar, "Exceptions and the run() Method," teaches you about exceptions in the context of a thread object's run() method.
Achieve strong performance with threads, Part 2
Developers sometimes create multithreaded programs that produce erroneous values or exhibit other strange behaviors. Odd behavior typically arises when a multithreaded program does not use synchronization to serialize thread access to critical code sections. What does it mean to serialize thread access to critical code sections? You'll find out as Jeff Friesen explains synchronization, Java's synchronization mechanism, and two problems that arise when developers fail to use that mechanism correctly. Once you finish this article, you should be able to avoid strange behavior that relates to lack of synchronization in your multithreaded Java programs.
Achieve strong performance with threads, Part 3
Jeff Friesen's four-part thread series continues with an investigation of thread scheduling, the wait/notify mechanism, and thread interruption. In Part 3, Friesen explains how priority relates to thread scheduling. You discover how to use the wait/notify mechanism to coordinate the activities of multiple threads. Plus, you learn how to use Java's thread interruption capability to terminate a running thread.
Achieve strong performance with threads, Part 4
In this final series article, Jeff Friesen completes his exploration of threads by focusing on thread groups, volatility, thread-local variables, timers, and the ThreadDeath class. Also, the accompanying sidebar, "Finalization and Threads," explores Java's finalization activity in the context of threads.
Apply the specific notification pattern to control the order of thread execution
The cross-platform nature of the Java platform is one of its major benefits. However, certain behaviors of the platform are less than desirable. One problem is the inability to consistently rely on which thread from a set of waiting threads will execute after a call to the notify() or notifyAll() method. We can solve the problem by specific notification -- programmatically choosing a particular thread to execute from a set of waiting threads. This precision is often critical to ensure the correct and consistent execution of code on the same or multiple platforms. Note: All of the code in this article was compiled and run with the IBM Java SDK, version 1.3.
Avoid synchronization deadlocks
Though essential for ensuring the thread safety of Java classes, synchronization, if used improperly, can create the possibility for deadlocks. If you understand how your programs use synchronization, and apply consistent rules for acquiring multiple locks simultaneously, you can reduce the likelihood of synchronization deadlock in Java programs.
Can double-checked locking be fixed?
This article looks at some of the commonly proposed fixes and shows how each of them fails to render the DCL idiom thread-safe under the Java Memory Model.
Can ThreadLocal solve the double-checked locking problem?
It has been suggested that java.lang.ThreadLocal can be used to fix the problems with the double-checked locking (DCL) idiom once and for all. ThreadLocal is indeed an underappreciated tool in the Java Class Library and does solve the thread-safety problems of DCL, but unfortunately it does not meet the performance objectives of DCL -- yet.
Designing for Thread Safety
This article gives you design guidelines pertaining to thread
safety. It provides a background on thread safety and shows
several examples of objects that are and are not thread-safe,
including two illustrative applets. In addition, the article
offers guidelines to help you decide when thread safety is
appropriate and how best to achieve it.
Ease your multithreaded application programming
The producer-consumer scenario is one of the most-used constructs in multithreaded application development -- and herein lies the rub. Because the producer-consumer behavior can be duplicated many times throughout a single application, so can the code. Software developers Ze'ev Bubis and Saffi Hartal have created the Consumer class, which works around this problem by facilitating code reuse and simplifying code debugging and maintenance in some multithreaded applications.
Introduction to Java threads
Threads enhance performance and functionality in various
programming languages -- including Java -- by allowing a
program to efficiently perform multiple tasks simultaneously.
Herein, we take a close look at the implementation of threads
using Java, and offer a step-by-step overview of the
fundamentals needed to incorporate threads into a Java program.
JavaBeans: properties, events, and thread safety
The JavaBeans standard is a 100% Pure Java creature, which means that the standard exists on top of established Java programming rules and conventions -- not alongside them. One technicality that Java programmers must always take into consideration is code reentrancy, or multithread safety. With bean properties and bean events, the two pillars of the JavaBeans standard, you must be keenly aware of this potential pitfall. The following article shows you why.
Lock on to an alternate synchronization mechanism
Tarak Modi shows how to create a reader/writer lock for multithreaded programming. That synchronization mechanism is useful if you don't want to prevent other threads from simultaneously reading a shared resource yet still want to allow only one thread to modify the resource. The implementation discussed here includes lock upgrade and downgrade capabilities. Enhancements such as lock-leasing, various performance improvement tips, and ways of dealing with issues such as priority inversion are also discussed.
Programming Java threads in the real world, Part 1
Programming Java threads isn't nearly as easy (or as platform-independent) as most books would have you believe, and all Java programs that use the AWT are multithreaded. This article is the first in a series that discusses the things you need to know to program threads in the real world. The article assumes you understand the language-level support for threads (the synchronized keyword, how monitors work, the wait() and notify() methods, and so on) and focuses on the legion of problems that arise when you try to use these language features.
Programming Java threads in the real world, Part 2
This article, the second in a multipart series on threads, discusses the perils that can arise when you approach multithreading in a naive way. As is the case with the entire series, this article assumes reader familiarity with the basic thread-related parts of Java: the synchronized keyword and monitors, wait(), notify(), the basics of using the Thread class, and so forth. Here, Allen focuses on the more advanced problems encountered when programming Java threads in the real world.
Programming Java threads in the real world, Part 3
In Parts 1 and 2 of this series on threads, Allen looked at some of the pitfalls of writing multithreaded applications in Java. This month, he starts looking at a few solutions. In particular, he looks at how and why you might want to roll your own exclusion semaphores, and presents a lock manager that will help you safely acquire multiple semaphores.
Programming Java threads in the real world, Part 4
This column continues where last month's column left off, presenting a few more implementations of classes that are useful when you're doing multithreading in Java. The two classes I'll discuss provide capabilities difficult to get using Java's threading primitives alone: a condition variable adds to wait the ability to not wait when the condition you're waiting for has already taken place; and a counting semaphore lets you control a pool of resources without sucking up machine cycles in polling loops. This month's column also discusses a few minor fixes to the code presented last month.
Programming Java threads in the real world, Part 5
This month's main topic is timers, both the one in the Swing library (called Timer) and also a roll-your-own variety called Alarm, which is useful when the Swing Timer isn't available or appropriate.
Programming Java threads in the real world, Part 6
This month continues the thread theme by examining how to implement the Observer pattern (used by AWT/Swing for its event model) in a multithreaded environment. The article covers how to notify observers in an efficient, thread-safe way using code modeled after Java's AWTEventMulticaster. It also considers a few problems with AWT/Swing's use of Observer.
Programming Java threads in the real world, Part 7
This month's column builds on the preceding installments of the Java Toolbox threads series, adding a few more tools to your multithreading arsenal. Columnist Allen Holub looks at reader/writer locks, which let multiple threads safely access a shared resource in an efficient way. (Multiple threads can read from the resource while only one thread at a time can write to it, and reads and writes can't occur at the same time.) He'll also discuss the Singleton pattern, with a focus on implementing it in a multithreaded environment, and critical sections, or blocks of code that can be executed by only one thread at a time.
Programming Java threads in the real world, Part 8
This month's (penultimate) installment in the thread series moves on to discuss architectural solutions to threading problems. Allen looks at threads from the perspective of an object-oriented designer, and at how to implement threads in an object-oriented environment, focusing on the implementation of asynchronous methods. Along the way, he discusses the Command design pattern. He also presents an architectural-level solution to the threading-complexity problem: the thread pool, which is useful for minimizing thread-creation overhead. And he introduces a realistic implementation of a blocking queue -- a form of queue that's useful for interthread communication that blocks any thread that attempts to remove an item from an empty queue. Finally, he demonstrates the practical application of a thread pool by showing you how to implement a server-side socket's accept loop efficiently.
Programming Java threads in the real world, Part 9
This article finishes up the series on threads with a discussion of two more architectural solutions to threading problems: a synchronous dispatcher (or "reactor") and an asynchronous dispatcher (or "active object"). These dispatchers can simplify the threading model considerably by letting you minimize -- and in some cases eliminate -- the need for method-level synchronization, thereby making it much easier to write and debug multithreaded applications. Both of these design patterns leverage the object-oriented view of threading discussed in last month's column. Allen demonstrates the active object architecture with an OutputStream derivative that allows two threads to simultaneously write to the console without getting the lines of text mixed together.
Secure thread collaboration across protection domains
When threads collaborate across protection domains, they introduce interesting wrinkles into the science of building secure applications. This month, Todd Sundsted presents these scenarios and shows how to use the AccessControlContext and GuardedObject classes to build solid solutions.
Simply Singleton
The Singleton pattern is one of the simplest design patterns, but for Java developers, it's full of pitfalls. In this month's column, David Geary explores the Singleton pattern and how to deal with its pitfalls while discussing multithreading, classloaders, and serialization.
Synchronization is not the enemy
Unlike many other programming languages, the Java Language Specification included explicit support for threading and concurrency. While having language support for concurrency makes it easier to specify and manage constraints on shared data and the timing of operations across threads, it doesn't make the complexities of concurrent programming any easier to understand. This three-part series aims to help programmers understand some of the major issues behind multithreaded programming in the Java language, and in particular to understand the impact of thread safety on Java program performance.
Synchronizing threads in Java, Part 1
Java's built-in multithreading capability makes it easy to build powerful multiprocessing applets. Synchronizing the activity of these separate executing entities is crucial to reliable and predictable applet behavior. Walk through a simple example illustrating the use of the wait() and notify() functions.
The taming of the thread
With MutableThread and ThreadWatchDog, you can make your threads come back to life and continue running seamlessly even after thread death.
Threads and applets and visual controls
In this final section we will add a new choice class, extend our Numeric class, and add a facility for reading multiple data channels at once (which is used in the new Numeric class).
Using threads in Java, Part 2
Herein, see firsthand how to write such a data channel class, and then create a simple example application that illustrates a real-world implementation of the class.
Using threads with collections, Part 1
Threads are an integral part of the Java language. Using threads, many algorithms, such as queue management systems, are easier to access than they are using polling and looping techniques. Recently, while writing a Java class, I found I needed to use threads while enumerating lists, and this uncovered some interesting issues associated with thread-aware collections. In this first part of a two-part series, I'll define the issues associated with multiple threads and collections, and I'll describe a collection that starts off simple but gets much more complicated on the way to becoming thread-aware.
Warning! Threading in a multiprocessor world
Many authors (myself included at one point) advocate the double-checked locking idiom to access a Singleton object in an intuitively thread-safe way. Unfortunately, for counterintuitive reasons, double-checked locking doesn't work. Double-checked locking, in fact, is characteristic of a whole slew of so-called tricks that purport to eliminate synchronization overhead. They seem to work on an intuitive level, but they don't work at all in practice. The situation is made even worse in multiprocessor environments, since a trick that indeed works on a single-processor box oftentimes won't work correctly on a multiprocessor box. This article explains why. Warning: it's assumed that you know how synchronized works.
Writing efficient thread-safe classes
Language-level support for locking objects and for inter-thread signaling makes writing thread-safe classes a snap. Here, simple programming examples are used to illustrate the powerful and intuitive development of thread-safe and efficient classes.
Network Magazine Provides information Technology (IT) and network managers with strategic analysis, views of emerging technologies and product reports....
subscribe now
Links
