Multithreaded programs consist of several threads that execute independently until they need to have access to a shared resource. In such cases, the threads need to synchronize to prevent so-called data races. Debugging such programs is difficult, because the nondeterminism inherent to multithreading programming usually makes consecutive runs of the same program different from each other.

In this paper, the authors report on a Java tool that is able to record the relative order in which synchronization operations happen, so that they can be replayed deterministically as many times as necessary. They use Lamport clocks, and instrument each class at load time so that it records the times at which each thread executes a synchronization operation in a file, which is used later to control the execution of the program.

The authors’ proposal seems to be quite efficient in practice, but it could be better, since it records the synchronization operations performed on every object, including those that are local to a thread. This is a waste of time, since the order in which the synchronization operations are executed on those objects depends on the current thread itself, and not on other threads.

For a general introduction to the motivation for, and the main problems regarding, the implementation of record/replay systems, I recommend Ronsse et al.’s paper [1].