I'd like to share something that has helped me discover and eliminate some bugs from my thread-handling code. This applies to my solution of having implemented locking in Data itself, and to my use of JUnit, but perhaps the same sort of thing could find application in your ongoing development. JUnit test cases have been great with regard to locating points at which my implementation deviated from the published interface. Testing the threaded code was something I initially thought could be done only in a functional test. I'm no Doug Lea, so if you find this solution to be flawed or kludgy, cut a little slack and let me know where it's wrong. It came down to my creating two extensions of java.util.TimerTask. These private classes take an instance of Data and a record number at construction. The current time in milliseconds is recorded. A timer task is scheduled with java.util.Timer with a known delay. Then the blocking call is made. When the blocking call returns, the time it took to run is calculated and compared to the known delay. The run time must be greater than/equal to the delay for the test to succeed. For example, one cannot lock record number 1 if all records are locked. A timer task is set to unlock all records after a delay. The test case goes to lock record 1. The call blocks as expected. The timer task removes the lock on all records after the delay is expired, and the call to lock record 1 proceeds. The time it took for the call to lock record 1 to return is then compared to the delay time. This helped me to find some errors and also to question if my implementation was true to Sun's requirements. Here's a clip from a unit test...
I used to create a timer. But now I agree with someone else, you needn't use the timer. Because the instruction said "no time out in lock." So, I delete them. YING REN
Joined: Nov 22, 2008
The timers are being used to test the threaded code. There are no timeouts in the implementation itself. A blocking condition is set first, then the timer task is scheduled to remove that blocking condition after a delay. The implementation is expected to block for the duration and then proceed once the timer task has done its thing.