ThreadSafe 1.3.1 released

ThreadSafe 1.3.1 is now available for ThreadSafe Solo and ThreadSafe Enterprise customers. A free trial is available, which includes the full functionality of ThreadSafe Solo for two weeks.

Both ThreadSafe Solo and trial licenses can be used with ThreadSafe for Eclipse and the ThreadSafe Command Line Interface, which are available as separate downloads.

A ThreadSafe Enterprise package includes multiple licenses for ThreadSafe for Eclipse and the ThreadSafe Command Line Interface, plus ThreadSafe for SonarQube to allow your team to see and track issues reported by ThreadSafe. It also includes enhanced, priority support.

ThreadSafe for SonarQube now supports SonarQube 4.2+

Download a free trial

What’s new in ThreadSafe 1.3.1?

ThreadSafe 1.3.1 includes 6 new rules, improvements to the accuracy of some existing rules, and many minor improvements to the Eclipse plug-in and Command Line Interface.

The new rules are:

Find deadlocks with ThreadSafe

ThreadSafe 1.3.1 includes a new rule for finding code that may be prone to deadlock because of the order that locks are acquired.

Suppose a thread already holding a lock, say lockA, attempts to acquire another lock, say lockB. Then suppose another thread already holds lockB and attempts to acquire lockA, then the two threads may deadlock.

When ThreadSafe detects code prone to deadlock, it reports which locks are held for each lock acquisition:

One solution for fixing this code is to ensure that threads will always acquire locks in the same order, say lockA and then lockB.

This is a very simple example. ThreadSafe also spots much more complex circular dependencies, including dependencies that cross class boundaries.

Find methods that do not release locks when an exception is thrown

Intrinsic locks —the type of lock used when using the synchronized keyword— are released at the end of the synchronized block. For synchronized methods, this means the lock is released when the method returns.

Lock objects provided by the java.util.concurrent.locks package, such as ReentrantLock and ReentrantReadWriteLock, support more sophisticated locking strategies, but care must be taken to release the locks, even when an exception is thrown.

The “Lock not released when method throws an exception” rule introduced in ThreadSafe 1.3.1 finds code that uses java.util.concurrent locks, but does not always release the lock when the method exits with an exception.

ThreadSafe reports the method, and the location in that method where a lock is acquired, but may not be released when the method returns:

A typical fix for this kind of bug is to use a finally block to release the lock.

Check for compliance with CERT LCK04-J

The CERT Oracle Secure Coding Standard for Java provides a set of recommended practices for secure programming in Java. These are grouped into a number of categories, several of which are relevant to writing concurrent programs. These include Visibility and Atomicity, Locking, Thread APIs, and Thread Pools.

ThreadSafe 1.3.1 extends coverage of the CERT Oracle standard to check for compliance with LCK04-J: “Do not synchronize on a collection view if the backing collection is accessible”. This refers to correct use of a collection returned by synchronized… methods on the java.util.Collections class, such as synchronizedList and synchronizedMap, when iterating over its view. Failure to follow this guidance can result in non-deterministic behaviour.

ThreadSafe 1.3.1 includes four rules covering different ways of violating LCK04-J. Providing four rules allows more precise guidance to be given about the violation, its potential consequences, and its remediation.

The first rule, Synchronizing on a collection view, reports code that synchronizes on a view, regardless of whether the code includes iteration over the view:

The second rule, No lock held while iterating over a synchronized collection view is reported on iteration over a synchronized collection view without synchronizing on the collection or the view:

The rule Iterating over a synchronized collection while holding a lock on the view is reported on code that synchronizes on both the backing collection and the view. Typically, this is not a bug that will cause serious problems, especially if the view is not shared between threads. However, it may indicate excessive locking.

The rule Iterating over a collection view whilst not locking on the backing collection is more likely to be a bug. It indicates that the code synchronizes on the collection view, but not the backing collection. This may indicate that the developer was aware of the need to synchronize on the collection, but has inadvertently synchronized on the wrong collection.

Try ThreadSafe today!

Download ThreadSafe Solo today and take a free trial, with full access to all the features of ThreadSafe Solo for two weeks.

Download a free trial