Years ago, after spending days trying to figure out a deadlock problem, I was told that (due to bugs in the JVM and/or OS) there were scenarios where Object.wait(0) could fail to return when it should and that I should never use an infinite blocking call on a monitor or lock. Adding a non-zero argument worked and I've used this pattern in all my code since.
For example, code that looks something like this:
synchronized (monitor) {
while (monitor_condition) {
monitor.wait(0L);
}
}
// or
lock.lock();
try {
while (lock_condition) {
condition.await();
}
} finally {
lock.unlock();
}
I instead write like this (and have for decades):
synchronized (monitor) {
while (monitor_condition) {
monitor.wait(1000L);
}
}
// or
lock.lock();
try {
while (lock_condition) {
condition.await(1L, TimeUnit.SECONDS);
}
} finally {
lock.unlock();
}
I was recently asked during a code review why I wrote my code like this and (after relating my war story) I decided to poke around on the Internet looking for current literature or work stories as to whether or not others continue to have similar deadlocking problems with the infinite blocking versions of wait and await. I turned up nothing.
As there is nothing technically incorrect with either of the above code blocks (my preferred approach simply using a few more CPU cycles than necessary) this question is more of a collective request for comments. I'll post my question here regardless for it is programming related.
Anyway, I was wondering whether anyone out there has experienced a so-called spurious deadlock (as compared to the spurious wakeup in the Java 1.[78] java documentation) using modern JVMs (e.g., 1.7+) where a monitor was notified or a condition signaled and the blocked thread failed to return from the infinite wait or await call?
i.e., given code to unblock the above example something along these lines:
synchronized (monitor) {
monitor_condition = false;
monitor.notifyAll();
}
// or
lock.lock();
try {
lock_condition = false;
condition.signalAll();
} finally {
lock.unlock();
}
has anyone observed behavior where, at code completion of the unblocking code, the wait or await methods from the first example above fail to return (stuck, as it were, in an infinite wait)?