Page History

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|AA. Java References#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.

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|AA. Java References#API 06]\] Class Vector, Class WeakReference
\[[JavaThreads 04|AA. Java References#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<stub>