Concutest Community Project

Welcome to the Concutest Community Project. This is an effort to allow community volunteers to identify the concurrency invariants that exist in the Java API. Anyone can participate. It’s free, all you need to do is register¹.

Please read the “About” and “An Example” pages to find out more about the Concutest Community Project.

The research staff of the Concutest project will periodically evaluate the posts on this blog and add new invariants to our publicly available database. All tools are (or will eventually be) open-source and free for anyone to use.

Thank you!

1. Privacy policy: We guarantee that we will never pass your email address on to anyone outside the core Concutest project, and that your password is safe and even unknown to us. [back]

TODO: Explain

TODO: Explain

TODO: Explain

TODO: Explain

TODO: Explain

TODO: Explain

TODO: Explain

TODO: Explain

Consider the invokeAndWait method in the javax.swing.SwingUtilities class:

You give it a Runnable, and Java will execute it in the event thread, and then return to you once that is done. This normally works, but what if you call the method from the event thread? In that case, Java will put the Runnable at the end of the event queue, and then wait for it to be executed, but it never will be executed, because the current event is waiting for that Runnable to finish. Calling javax.swing.SwingUtilities.invokeAndWait from within the event thread is a recipe for an instant deadlock!

Therefore, the concurrency invariant for that method is “do not run it in the event thread”.

This invariant can be ensured by prefixing the invokeAndWait method with the Concutest ThreadChecker annotation @NotEventThread:

package javax.swing;
 
import edu.rice.cs.cunit.threadCheck.predicates.NotEventThread;
// …
public class SwingUtilities {
  // …
  @NotEventThread
  public static void invokeAndWait(Runnable doRun)
    throws InterruptedException, InvocationTargetException {
    // …
  }
  // …
}