Refactoring for Reentrancy

I'm glad this article used test cases as examples where reentrancy can be used because earlier this year, I ran into issues running JUnit tests on a multi-threaded application that depended on each execution to be independent from the other. I had to manually re-initialize persistent data after each run. Now I at least know one can wrap static variables with ThreadLocal and use TestRunner to spawn threads that utilize their own copy :-). Aside from testing, other applications for reentrancy are in interrupt handlers where interrupts can be dispatched to multiple cores.

Given that I have limited experience with using reentrancy for creating multithreading applications, it appears to me that the solution does provide a solution that makes a program reentrant. Ideally, all variables would be local so as to avoid the whole transformation of static variables but it's understandable that this is used for legacy code. However, the transformation makes the code look really ugly in this simple example so I'm having a hard time figuring out how this would scale in an enterprise application.

On a side note, I don't think object fields need to be made thread-local if a new instance is created for each execution. Also, I don't think shared resources such as standard output or a printer can be thread-local. In the paper, they circumvented this by outputting to a logger as opposed to standard output. In cases where it's necessary to output to a printer or standard output, one may have to introduce a mechanism for serializing the output in a predictive order. And finally, reentrancy does imply thread-safety because multiple threads can execute the same code without interfering with each other. But thread-safety does NOT imply reentrancy because thread-safety cannot guarantee a method would return the same output for a given input each time its executed.