Designing for Thread Safety. Designing for Thread SafetyUsing Synchronization, Immutable Objects, and Thread-Safe Wrappersby Bill VennersFirst Published in JavaWorld, July 1998 << Page 3 of 11 >> Throwing a concurrent wrench into the works Unfortunately, this happy picture of a well-behaved RGBColor object can turn scary when other threads enter the picture.
In a multithreaded environment, instances of the RGBColor class defined above are susceptible to two kinds of bad behavior: write/write conflicts and read/write conflicts. Write/write conflicts Imagine you have two threads, one thread named "red" and another named "blue. " Both threads are trying to set the color of the same RGBColor object: The red thread is trying to set the color to red; the blue thread is trying to set the color to blue. Both of these threads are trying to write to the same object's instance variables concurrently.
To step through the sequence of events that lead to a corrupted RGBColor object, press the applet's Step button. Design for thread safety. Six months ago I began a series of articles about designing classes and objects.
In this month's Design Techniques column, I'll continue that series by looking at design principles that concern thread safety. This article tells you what thread safety is, why you need it, when you need it, and how to go about getting it. What is thread safety? Thread safety simply means that the fields of an object or class always maintain a valid state, as observed by other objects and classes, even when used concurrently by multiple threads. One of the first guidelines I proposed in this column (see "Designing object initialization") is that you should design classes such that objects maintain a valid state, from the beginning of their lifetimes to the end. Multiple threads can spell trouble for your object because often, while a method is in the process of executing, the state of your object can be temporarily invalid.
Why worry about thread safety? RGBColor #1: Ready for a single thread. Using ReentrantLock for thread synchronization « a cup of java. ReentrantLock was introduced in Java 1.5.
This can be considered as a replacement for the traditional “wait-notify” method. The basic concept is, every thread need to acquire the lock before entering in to the critical section and should release it after finishing it. And its the most basic concept of synchronization. ReentrantLock eliminates the use of “synchronized” keyword. Using optional “fairness” parameter with ReentrantLockReentrantLock accepts an optional “fairness” parameter in it’s constructor. But if we are specifying the fairness parameter as “true” while creating a new ReentrantLock object, it gives us the guaranty that the longest waiting thread will get the lock next. Use of “Condition” in ReentrantLockCondition can be considered as a separation of monitor methods (wait(), notify() & notifyAll()).
Some useful links Like this: Like Loading... Thread Pools (The Java™ Tutorials > Essential Classes > Concurrency) Most of the executor implementations in java.util.concurrent use thread pools, which consist of worker threads.
This kind of thread exists separately from the Runnable and Callable tasks it executes and is often used to execute multiple tasks. Using worker threads minimizes the overhead due to thread creation. Thread objects use a significant amount of memory, and in a large-scale application, allocating and deallocating many thread objects creates a significant memory management overhead. One common type of thread pool is the fixed thread pool. This type of pool always has a specified number of threads running; if a thread is somehow terminated while it is still in use, it is automatically replaced with a new thread. An important advantage of the fixed thread pool is that applications using it degrade gracefully. The newCachedThreadPool method creates an executor with an expandable thread pool.