RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

[Hans Boehm]

In general, this seems much easier to get right with a timed wait that
takes an absolute deadline instead of a relative timeout interval.
Condition seems to have such a method, but it doesn't appear the easiest to
use. I'm not quite sure what the right Java API would look like.

On Mon, Aug 21, 2017 at 8:32 AM, Martin Buchholz <martinrb at google.com>
wrote:

>
>
> On Sun, Aug 20, 2017 at 9:53 PM, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> On 21/08/2017 2:07 PM, Martin Buchholz wrote:
>>
>>> On Sun, Aug 20, 2017 at 6:36 PM, David Holmes <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>     On 20/08/2017 6:37 AM, Martin Buchholz wrote:
>>>
>>>         Future projects:
>>>
>>>         377 * <li>The specified amount of real time has elapsed, more or
>>>         less.
>>>
>>>         Replace with
>>>
>>>         * <li>At least the specified amount of real time has elapsed.
>>>
>>>         (I think I failed to persuade David last time ...)
>>>
>>>
>>>     And you will continue to do so. :) In the presence of spurious
>>>     wakeups it is completely untestable to say "at least the specified
>>>     time has elapsed"
>>>
>>>
>>> My view is that spurious wakeup is a separate item in this list. "The
>>> specified amount of real time has elapsed" should only be about "normal"
>>> timeout.
>>>
>>
>> And if you could perform whitebox testing that peeks inside to be able to
>> make the distinction that would be fine. But in terms of the API and any
>> conformance test, it is impossible to distinguish between an "early return"
>> and a "spurious return". So specifying "at least ..." is meaningless so
>> long as spurious wakeups are allowed.
>>
>
> The testability difference is that regular timeout is "normal" whereas
> spurious wakeup must be "rare" (although of course "rare" is hard to pin
> down).
> Before we fixed
> 8065372: Object.wait(ms, ns) timeout returns early
> <https://bugs.openjdk.java.net/browse/JDK-8065372>
> returning early was unacceptably common
>