CON38-J. Ensure atomicity of thread-safe code

Thread-safety guarantees that no two threads can simultaneously access or modify some shared data. However, if two or more operations need to be performed safely, it becomes necessary to enforce atomicity. It is possible for two threads to read some shared value, independently perform operations on it and induce a race condition while storing the final result. Programmers usually assume that a thread-safe Collection does not require explicit synchronization which can be a misleading practice. It follows that a thread-safe Collection may not ensure program correctness.

Noncompliant code Example

This noncompliant example is comprised of an ArrayList collection which is non-thread-safe by default. There is however, a way around this drawback. Most thread-unsafe classes have a synchronized thread-safe version, synchronizedList being a good substitute for ArrayList. One pitfall described in the coming lines, remains to be addressed even when the particular Collection offers thread-safety benefits.

The operations within the run() method are non-atomic. That is, it is possible that the first thread will operate on data that it does not expect. The superfluous data may be fed in by other threads while the first thread has not finished processing. Conversely, since the toArray() method produces a copy of the parameter, it is possible that the first thread operates on stale data [[JavaThreads 04]]. The code's output with varying array lengths signifies a race condition. Such omissions can be pernicious in methods that use complex formulas.

class RaceCollection implements Runnable {
  private List<InetAddress> ips = Collections.synchronizedList(new ArrayList<InetAddress>());
  
  public void addIPAddress(InetAddress ia) {
    synchronized(ips) {
      ips.add(ia);
    }
  }

  public void removeIPAddress(InetAddress ia) {
    synchronized(ips) {
      ips.remove(ia);
    }
  }

  public void nonAtomic() throws InterruptedException {
    InetAddress[] ia;   

    synchronized(ips) {
      ia = (InetAddress[]) ips.toArray(new InetAddress[0]);     
    }
         
    System.out.println("Number of IPs: " + ia.length); 
  }
  
  public void run() {
    try {
      addIPAddress(InetAddress.getLocalHost());
      nonAtomic();
    } catch (UnknownHostException e) { }
      catch (InterruptedException e) { }		
  }
  
  public static void main(String[] args) {
    RaceCollection rc1 = new RaceCollection();
    for(int i=0;i<2;i++)
      new Thread(rc1).start();	  	  
  }
}

Compliant Solution

To eliminate the race condition, ensure atomicity. This can be achieved by including all statements that use the array list within the synchronized block.

synchronized(ips) {
  ia = (InetAddress[]) ips.toArray(new InetAddress[0]);           
  System.out.println("Number of IPs: " + ia.length); 
}

Note that this advice applies to all Collection classes including the thread-safe hash tables. Enumerations of the objects of a Collection and iterators also require explicit synchronization on the Collection object or any single lock object.

Although expensive, CopyOnWriteArrayList and CopyOnWriteArraySet classes are sometimes used to create copies of the core Collection so that iterators do not fail with a runtime exception when some data in the Collection is modified. These however, suffer from the toArray dilemma (operating on stale data) described earlier in this rule. Therefore their use is limited to boosting performance in code where the writes are fewer (or non-existent) as compared to the reads [[JavaThreads 04]]. In all other cases they must be avoided.

Risk Assessment

Non-atomic code can induce race conditions and affect program correctness.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[API 06]] Class Vector, Class WeakReference
[[JavaThreads 04]] 8.2 "Synchronization and Collection Classes"

MSC00-J. Eliminate class initialization cycles      49. Miscellaneous (MSC)      MSC02-J. Be aware of the JVM Tool Interface