Thoughts on Refactoring for Reentrancy

This paper is the third paper we read in CS527 regarding refactoring an aspect of Java program to enable it to run concurrently. This time it is to about making a Java program reentrant. As the other two papers, Jan Wloka, Manu Sridharan, and Frank Tip first characterize and analyze non-reentrant Java programs and propose steps to refactor them. After, they provide a semi-automatic Eclipse refactoring plugin and evaluate the tool to be both useful and efficient.

One major factor that makes a Java program non-reentrant is having global state. Thus, the refactoring involves replacing it and its static initialization with thread-local state and explicit lazy-initialization. Although doing so will affect the timing of the initialization but it is the authors' experience that such change often does not affect outcome.

While reading through it, I have a lingering doubt that such refactoring only work with the type of global state that does not correlate to the number of times the program is executed. For example, if there is a global state, counter, that tracks the number of times a program is called to perform a certain action, then this refactoring would not work as it does not increment a single copy of the counter. In this case, one will need to rely on other technique such as marking the global state synchronized. Granted that I don't use Java in my daily work but I think there are many cases with the global states that fall under this category. Since the authors do not explicitly call this out, I am still not sure.