wait finishes early?

[mikew01]

I am trying to write a method that detects when a thread has timed out
waiting for a resource, for brevity I have included the important
parts below in the lock method.
I am finding that when I specify a value of around 6000ms and above
the period is calculated lower than the timeout which results in the
code thinking that the thread has not timed out waiting but has simply
been released from a notify.
It appears that either wait( timeout ) is releasing early or I am not
using the correct method for gauging the time to obtain period.

Any ideas?

Thanks

public void lock( Object requester, long timeout ) throws
InterruptedException
{
long start = System.currentTimeMillis();

synchronized ( requester )
{
requester.wait( timeout );
}

long period = System.currentTimeMillis() - start;

if ( period >= timeout )
{
System.out.println( "Timed out waiting for resource: " +
period );
}
}

 

[Eric Sosman]

I am trying to write a method that detects when a thread has timed out
waiting for a resource, for brevity I have included the important
parts below in the lock method.
I am finding that when I specify a value of around 6000ms and above
the period is calculated lower than the timeout which results in the
code thinking that the thread has not timed out waiting but has simply
been released from a notify.
It appears that either wait( timeout ) is releasing early or I am not
using the correct method for gauging the time to obtain period.

Any ideas?

Thanks

public void lock( Object requester, long timeout ) throws
InterruptedException
{
long start = System.currentTimeMillis();

synchronized ( requester )
{
requester.wait( timeout );
}

long period = System.currentTimeMillis() - start;

if ( period >= timeout )
{
System.out.println( "Timed out waiting for resource: " +
period );
}
}

It's possible you're getting spurious wakeups: Situations
where wait() returns for "no good reason." But these should
be fairly rare, and I've even seen it claimed that some JVM's
take steps to prevent them. So if you're getting a lot of
these premature wakeups, there's probably something else afoot.

A second possibility can be seen in the Javadoc: The waiting
thread will awaken "after the specified amount of real time has
elapsed, *more or less*" [emphasis mine]. This suggests that
the guarantees on the duration of the wait() may not be as
tight as you'd like.

Still another possibility is that something *is* actually
calling notify() or notifyAll(), or is interrupting the waiting
thread. What steps have you taken to rule this out?

Finally, the return from wait() does *not* mean that the
condition you're waiting for has come true, or even if it has
that it still holds. You should always be using wait() along
with some kind of test to see whether you should take action,
wait longer, or give up -- just the wait() alone isn't enough.

 

[John B. Matthews]

I am trying to write a method that detects when a thread has timed
out waiting for a resource, for brevity I have included the important
parts below in the lock method. I am finding that when I specify a
value of around 6000ms and above the period is calculated lower than
the timeout which results in the code thinking that the thread has
not timed out waiting but has simply been released from a notify.
It appears that either wait( timeout ) is releasing early or I am not
using the correct method for gauging the time to obtain period. [...]
synchronized ( requester )
{
requester.wait( timeout );
}

[...]

"Always invoke wait inside a loop that tests for the condition being
waited for."

<http://java.sun.com/docs/books/tutorial/essential/concurrency/guardmeth.
html>
<http://java.sun.com/javase/6/docs/api/java/lang/Object.html#wait(long)>
<http://www.javaconcurrencyinpractice.com/>

 

[markspace]

I am trying to write a method that detects when a thread has timed out
waiting for a resource,...
the period is calculated lower than the timeout which results in the
code thinking that the thread has not timed out waiting but has simply
been released from a notify.

This is a terrible idea that can't ever work correctly, for a variety of
reasons.

You must get your threads to return status, like SUCCESS or TIMEOUT, and
your waiting thread must read that status to determine what the thread
did. Only your thread really knows for sure what happened, it's the
only way. Time based solutions will fail because you can't measure time
accurately enough to tell what happened.

I'd recommend that your threads use the Callable interface, and your
waiter use its Future object to wait and determine status.

You'll have to roll your own exits status, but that should be easy.

enum ExitStatus { SUCCESS, TIMEOUT }

should do it.

Future<ExitStatus> ... etc.

 

[mikew01]

This is a terrible idea that can't ever work correctly, for a variety of
reasons.

You must get your threads to return status, like SUCCESS or TIMEOUT, and
your waiting thread must read that status to determine what the thread
did.  Only your thread really knows for sure what happened, it's the
only way.  Time based solutions will fail because you can't measure time
accurately enough to tell what happened.

I'd recommend that your threads use the Callable interface, and your
waiter use its Future object to wait and determine status.

You'll have to roll your own exits status, but that should be easy.

   enum ExitStatus { SUCCESS, TIMEOUT }

should do it.

   Future<ExitStatus> ... etc.

Thanks for the suggestions.

 

[Mike Schilling]

I am trying to write a method that detects when a thread has timed
out waiting for a resource, for brevity I have included the
important
parts below in the lock method. I am finding that when I specify a
value of around 6000ms and above the period is calculated lower
than
the timeout which results in the code thinking that the thread has
not timed out waiting but has simply been released from a notify.
It appears that either wait( timeout ) is releasing early or I am
not
using the correct method for gauging the time to obtain period.
[...]
synchronized ( requester )
{
requester.wait( timeout );
}

[...]

"Always invoke wait inside a loop that tests for the condition being
waited for."

<http://java.sun.com/docs/books/tutorial/essential/concurrency/guardmeth.
html>
<http://java.sun.com/javase/6/docs/api/java/lang/Object.html#wait(long)>
<http://www.javaconcurrencyinpractice.com/>

This looks to me like the correct logic, encapsulated reasonably well:

public class EventUtils
{
public static void waitforEvent(
long maxDelay, Object lock, EventChecker checker)
throws InterruptedException
{
synchronized(lock)
{
long start = System.currentTimeMillis();
long toWait = maxDelay;
while (true)
{
lock.wait(toWait);
if (checker.isDone())
break;
if (maxDelay > 0)
{
long elapsed = System.currentTimeMillis() - start;
if (elapsed >= maxDelay)
break;
toWait = maxDelay - elapsed;
}
}
}
}

public interface EventChecker
{
boolean isDone();
}
}

 

[Daniel Pitts]

This looks to me like the correct logic, encapsulated reasonably well:

public class EventUtils
{
public static void waitforEvent(
long maxDelay, Object lock, EventChecker checker)
throws InterruptedException
{
synchronized(lock)
{
long start = System.currentTimeMillis();
long toWait = maxDelay;
while (true)

// Almost correct, should use:
while (!checker.isDone())
// because we don't want to wait if the event has already completed.

{
lock.wait(toWait);
if (checker.isDone())
break;
if (maxDelay > 0)
{
long elapsed = System.currentTimeMillis() - start;
if (elapsed >= maxDelay)
break;
toWait = maxDelay - elapsed;
}
}
}
}

public interface EventChecker
{
boolean isDone();
}
}

Using Lock and Condition classes may be a better choice for some code bases.