Thread-Safe - volatile, synchronized & atomic

The usual way of ensuring thread safety is though locking mechanism via synchronized blocks/methods
Example:

public class MySync {
private int value;

public int getValue(){
return value;
}
//Sync Method
public synchronized void setValue(int v){
value=v;
}

public void performCriticalTask(){
String task="KILL";
//Sync Block
synchronized(this){
//TODO: perform critical task with locking 'this'
}

}
}

Though this is a proven method,too much of locking can be a overhead for the system performance.

There are other alternatives which can be explored and carefully used along with locking for better thread-safe systems.

1. Use of volatile variables
2. Use of new JDK 5 feature java.util.concurrent.atomic

volatile:

Marking a variable as volatile means that the current value is always referred irrespective of state of the object. This means that threads will automatically see the most up-to-date value for volatile variables thus facilitating simpler way of thread safety.However this can be used only under following restricted set of circumstances.

1. Writes to the variable do not depend on its current value.
2. The variable does not participate in invariants with other variables.

Basically, these conditions state that the set of valid values that can be written to a volatile variable is independent of any other program state, including the variable's current state.

So, where can we use volatile safely.

status flags

Perhaps the canonical use of volatile variables is simple boolean status flags, indicating that an important one-time life-cycle event has happened, such as initialization has completed or shutdown has been requested.

Many applications include a control construct of the form, "While we're not ready to shut down, do more work," as shown following example:

Using a volatile variable as a status flag

volatile boolean shutdownRequested;

...

public void shutdown() { shutdownRequested = true; }

public void doWork() {
while (!shutdownRequested) {
// do stuff
}
}

It is likely that the shutdown() method is going to be called from somewhere outside the loop -- in another thread -- and as such, some form of synchronization is required to ensure the proper visibility of the shutdownRequested variable. (It might be called from a JMX listener, an action listener in the GUI event thread, through RMI, through a Web service, and so on.) However, coding the loop with synchronized blocks would be much more cumbersome than coding it with a volatile status flag as in Listing 2. Because volatile simplifies the coding, and the status flag does not depend on any other state in the program, this is a good use for volatile.

One common characteristic of status flags of this type is that there is typically only one state transition; the shutdownRequested flag goes from false to true and then the program shuts down. This pattern can be extended to state flags that can change back and forth, but only if it is acceptable for a transition cycle (from false to true to false) to go undetected. Otherwise, some sort of atomic state transition mechanism is needed, such as atomic variables.

the "volatile bean" pattern

The volatile bean pattern is applicable in frameworks that use JavaBeans as "glorified structs." In the volatile bean pattern, a JavaBean is used as a container for a group of independent properties with getters and/or setters. The rationale for the volatile bean pattern is that many frameworks provide containers for mutable data holders (for instance, HttpSession), but the objects placed in those containers must be thread safe.

In the volatile bean pattern, all the data members of the JavaBean are volatile, and the getters and setters must be trivial -- they must contain no logic other than getting or setting the appropriate property. Further, for data members that are object references, the referred-to objects must be effectively immutable. (This prohibits having array-valued properties, as when an array reference is declared volatile, only the reference, not the elements themselves, have volatile semantics.) As with any volatile variable, there may be no invariants or constraints involving the properties of the JavaBean. An example of a JavaBean obeying the volatile bean pattern is shown in following example.

A Person object obeying the volatile bean pattern

@ThreadSafe
public class Person {
private volatile String firstName;
private volatile String lastName;
private volatile int age;

public String getFirstName() { return firstName; }
public String getLastName() { return lastName; }
public int getAge() { return age; }

public void setFirstName(String firstName) {
this.firstName = firstName;
}

public void setLastName(String lastName) {
this.lastName = lastName;
}

public void setAge(int age) {
this.age = age;
}
}

Volatile variables are a simpler -- but weaker -- form of synchronization than locking, which in some cases offers better performance or scalability than intrinsic locking. If you follow the conditions for using volatile safely -- that the variable is truly independent of both other variables and its own prior values -- you can sometimes simplify code by using volatile instead of synchronized. However, code using volatile is often more fragile than code using locking. The patterns offered here cover the most common cases where volatile is a sensible alternative to synchronized. Following these patterns -- taking care not to push them beyond their limits -- should help you safely cover the majority of cases where volatile variables are a win.

Java 5 Atomicity

The volatile cannot be used for thread-safe counters due to the fact that "Volatile can write to the variable do not depend on its current value". While the increment operation (x++) may look like a single operation, it is really a compound read-modify-write sequence of operations that must execute atomically -- and volatile does not provide the necessary atomicity. Correct operation would require that the value of x stay unchanged for the duration of the operation, which cannot be achieved using volatile variables.

JDK 5 enables this by providing new package java.util.concurrent.atomic.This is a small toolkit of classes that support lock-free thread-safe programming on single variables.

This package comprises of classes -AtomicInteger; AtomicLong; AtomicReference; AtomicBoolean; array forms of atomic integer; long; reference; and atomic marked reference and stamped reference classes, which atomically update a pair of values.

Following example illustrates how to use AtomicInteger for any CAS operations

package org.nava.jfive.concurrent;

import java.util.concurrent.atomic.AtomicInteger;

public class MyAtomicOperation {
private AtomicInteger value;

public static void main(String[] args) {
MyAtomicOperation myOp=new MyAtomicOperation();
myOp.setValue(new AtomicInteger(10));
TestThread tt1=new TestThread(myOp);
TestThread tt2=new TestThread(myOp);
tt1.start();
tt2.start();
}


public AtomicInteger getValue() {
return value;
}

public void setValue(AtomicInteger value) {
this.value = value;
}

}

class TestThread extends Thread {

MyAtomicOperation myOp;

public void run(){
int test=myOp.getValue().incrementAndGet();
System.out.println(Thread.currentThread().getName()+"|"+test);
}
public TestThread(MyAtomicOperation myOp) {
super();
this.myOp = myOp;
}

}