On 19/11/2014 2:02 AM, Martin Buchholz wrote:
On Mon, Nov 17, 2014 at 9:02 PM, David Holmes <david.hol...@oracle.com> wrote:
Hi Martin,
On 18/11/2014 2:49 PM, Martin Buchholz wrote:
Hi David,
I'm still hoping to persuade you (and others) to fix the long-standing
return-early bug in Object.wait.
Are you referring to the low level mechanics or specifically to the
nanosecond version below?
Here I'm just trying to fix the problem that Object.wait(millis,nanos)
trivially returns early.
That seems overly complex - after checking for valid values of timeout and
nanos you simply need:
if (nanos > 0) timeout++;
to ensure the >= requirement.
Sure, the miminal diff is:
diff --git a/src/java.base/share/classes/java/lang/Object.java
b/src/java.base/share/classes/java/lang/Object.java
--- a/src/java.base/share/classes/java/lang/Object.java
+++ b/src/java.base/share/classes/java/lang/Object.java
@@ -453,7 +453,7 @@
"nanosecond timeout value out of range");
}
- if (nanos >= 500000 || (nanos != 0 && timeout == 0)) {
+ if (nanos != 0) {
timeout++;
}
I can live with that. Though given spurious wakeups it doesn't add much.
But seriously we should just deprecate this version as we're not likely to
get any underlying OS mechanisms for doing nanosecond resolution timed
blocking actions.
Object.wait(millis, nanos) is an ugly API (I wish for both a public
and hotspot internal API that simply operated on nanoseconds), but
it's not totally awful. It's not obvious to me that computing
advances over the lifetime of the java platform won't allow
sub-millisecond scheduling, and other APIs that do operate on
nanoseconds (like Process.waitFor) should call this API.
I'm sure the same thing was said 20 years ago, yet the OS seem stuck at
microsecond resolution. Maybe one day ...
David
