Excellent question. The answer is a I truely dont know.

My initial reaction would be to tell you not to get too wrapped up in
very small performance considerations (especially in loops where you
wait for much longer periods of time) and go with the version you
prefer from a style and form perspective.

If you think this could result in a big performance bottleneck (if the
thread could be woken > 100 times a second), then the best thing to do
would be to run a few simple benchmarks and see what you get.

When designing an system, don't worry so much about overhead and speed.
Why? Once you have an easy to understand system in place, it is easier
to change small areas of the system without destroying others.  Once
you have this, run a profiler.  The profiler will tell you where your
system is taking the most time.

You would often be surprised by what actually takes time in your
system. I've been surprised many times myself.  I once thought I was
going to have to find a new algorithm for drawing an arc, but it turned
out the delay was caused by a slow angle addition.  It was a much
easier fix.

In any case, I think you'll still need a thread.  waitLock.wait(time);
will block the thread that executes it.  Also, wait isn't guarantied to
block the full time, even if no notify is called.

The best way to handle this is to have some sort of condition in a
loop.

public void waitToStartProcessing() throws InterruptedException {
   long timeUntilEnd = System.currentTimeMillis() + pollSeconds *
1000;
   while (System.currentTimeMillis() < timeUntilEnd) {
         synchronized(waitLock) {
               waitLock.wait(timeUntilEnd -
System.currentTimeMillis());
         }
   }
}

public void processWhenReady() throws InterruptedException {
  waitToStartProcessing();
  doProcessing();
}

public void forceProcessing() {
     synchronized(waitLock) {
           waitLock.notifyAll();
     }
}

Hope this helps.

Daniel.