Page History

...

Automated Detection

Static analysis tools, such as FindBugs and PMD, do not detect problems with the noncomplient solutions shown above without some "hint" that the program code is intended to be thread-safe. For example, consider the complient code below where the use of a synchronized method is a hint to analysis tool that the class is intended to be used concurrently.

public class Foo {
  private boolean flag = true;

  public synchronized boolean toggleAndGet() {
    flag ^= true; // same as flag = !flag;
    return flag;
  }
}

FindBugs and PMD will not report a warning about this implementation as they do not note any problems. SureLogic JSure, a verification tool, will complain that the lock is unknown to the tool and ask the user to annotate what state the lock protects, i.e., the tool wants to know the locking policy that the programmer intends for this class. To express this intent, the programmer adds two annotations:

@RegionLock("FlagLock is this protects flag")
@Promise("@Unique(return) for new()")
public class Foo {
  private boolean flag = true;

  public synchronized boolean toggleAndGet() {
    flag ^= true; // same as flag = !flag;
    return flag;
  }
}

The @RegionLock annotation creates a locking policy, named FlagLock, that specifies that reads and writes to the field flag are to be guarded by a lock on the receiver, i.e., this. The second annotation, @Promise is used to place an annotation on the default constructor generated by the compiler. The @Unique("return") annotation promises that the receiver is not aliased during object construction, i.e., that a race condition cannot occur during construction. (CON14-J. Do not let the "this" reference escape during object construction provides further details.) If the constructor was explicit in the code then the annotations would be:

@RegionLock("FlagLock is this protects flag")
public class Foo {
  private boolean flag;

  @Unique("return")
  public Foo() {
    flag = true;
  }

  public synchronized boolean toggleAndGet() {
    flag ^= true; // same as flag = !flag;
    return flag;
  }
}

The JSure verification tool provides a strong assurance that the annotated model holds for all possible executions of the program. If the below code noncompliant code is later added to the class,

  public boolean getValue() {
    return flag;
  }

then JSure will report the violation of the locking policy to the user.

If the noncompliant getValue() method shown above is defined in the code for Foo, then FindBugs can also report a problem, again if the locking model is annotated. However, it uses a different annotation than JSure.

public class Foo {
  @GuardedBy("this")
  private boolean flag = true;

  public synchronized boolean toggleAndGet() {
    flag ^= true; // same as flag = !flag;
    return flag;
  }

  public boolean getValue() {
    return flag;
  }
}

With the @GuardedBy annotation in place, and only with this annotation in place, FindBugs reports that the field is not guarded against concurrent access in the getValue() method.

TODO Describe concurrency-focused analysis tools.

Related Vulnerabilities

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

...