I’m working with the simple examples for my thesis again, and I realized another interesting thing: Synchronized methods are harder to protect than non-synchronized methods.
The example that I’m using is this:
import edu.rice.cs.cunit.threadCheck.SuppressSubtypingWarning;
import edu.rice.cs.cunit.threadCheck.predicates.NoneSynchronizedField;
public class BenignCall extends Benign {
private static Object o = new Object() {
public synchronized String toString() { return "foo"; }
};
public static void main(String[] args) {
final Benign b = new BenignCall();
synchronized(o) {
Thread aux = new Thread(new Runnable() {
@SuppressSubtypingWarning
@NoneSynchronizedField(fieldClass=BenignCall.class,fieldName="o")
public void run() {
b.run(o, o);
}
});
aux.start();
try { aux.join(); } catch(InterruptedException e) { }
}
// b.run(o,o); would have worked
}
}
I’m using a @NoneSynchronizedField annotation to express the invariant that no thread may hold the lock of the o field at the time the Runnable.run() method is invoked.
I just looked at it again and thought it would be much more natural to state that the lock of this may not be held when the overloaded toString() method is called:
@NoneSynchronizedThis
public synchronized String toString() { return "foo"; }
But I realized this wouldn’t work. With synchronized methods, Java grabs the lock automatically, behind the scenes, and by the time code in the method is executed, the lock is already held. Or not, in this example, the program may deadlock.
I think with this in mind, it may be a good idea to convert all synchronized methods to methods containing synchronized blocks [1], something that I already do quite often.
Update: I now have a parameter “convert-sync-methods” that can be passed to the Thread Checker instrumentation strategy that converts synchronized methods to methods containing synchronized blocks. So now the @NoneSynchronizedField annotation can be used there.
