Delay Balance

I’ve just finished the last instrumentor to delays to programs. That means my instrumentation is currently inserting delays before

  • monitorenter
  • Object.wait
  • Object.notify
  • Object.notifyAll
  • Thread.join
  • Thread.exit

and delays after

  • monitorenter
  • monitorexit
  • Object.wait
  • Thread.join
  • Thread.start

After I added delays before and after calls to Object.wait, though, the test case with the early notification wasn’t hanging anymore. I think because now I have delays in all the important places, on average the delays often balance out and preserve the original order.

I think what I want to do is try to skew the schedule maximally in one way and then in the other, e.g. first put delays on wait but not on notify, then in another run do it the other way around.

The following of those relationships come to mind:

  • Object.wait vs. Object.notify, Object.notifyAll
  • vs. Thread.join
  • vs. Thread.start
  • Thread.exit vs. Thread.start

There are many combinations here, especially since some of these sync points may have delays before and after them. I definitely need to investigate the relationships more closely… when I’m more awake.


Another idea instead of random delays are calls to Thread.yield that occur randomly.


About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in Concurrent Unit Testing. Bookmark the permalink.

Leave a Reply