Right now, I’m actually not so sure that I really want to decrement the number of running threads before a monitorenter, Object.wait or Thread.join. A thread could reach a monitorenter, check the counter and think there is only one active thread, but right after the check was made and before the monitorenter is actually reached another thread continues to run, leaves its monitorenter and increments the count. In this case, no delay would be executed, even though I think there should be one because of potential subtle interactions between the two threads. The same situation could happen twice, and then both threads are unaware that there actually is concurrency in the program. I think I am just going to increment and decrement in Thread.start and Thread.exit.
Another suggestion Corky made that I just remembered was that when no threads are spawned and there was no concurrency, then the test should indicate that somehow to reduce the number of repetitions of that test, perhaps even not repeating the test at all. That’s not really conservative, though. but yet again, it might be sufficient.
I also need to come up with a few good examples of synchronization bugs that this technique can catch.
