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

[Martin Buchholz]

awaitUntil(Date)
<http://download.java.net/java/jdk9/docs/api/java/util/concurrent/locks/Condition.html#awaitUntil-java.util.Date->
is
weird in that it takes a wall clock Date that is subject to system
administrator action like date(1).  And Date is one of those classes
everyone loves to hate.

Using a nanoTime deadline in the API had never occurred to me.  Using a
duration in the API is more natural.  It seems reasonable to try to push
complexity of recomputing wait times to the library.  OTOH it introduces
weirdness of nanoTime wraparound, which the wait API would need to
explain.  There's a pitfall where a call poll(Long.MIN_VALUE, NANOSECONDS)
might end up wrapping to a positive wait near Long.MAX_VALUE, if the
implementor of poll failed to check for a negative timeout.  Maybe I'm
talking myself into an advocate for Guava Monitor
<https://google.github.io/guava/releases/21.0/api/docs/com/google/common/util/concurrent/Monitor.html#enterWhen-com.google.common.util.concurrent.Monitor.Guard-long-java.util.concurrent.TimeUnit->
which
I have also done some work on.

On Tue, Aug 22, 2017 at 9:21 PM, Hans Boehm <hboehm at google.com> wrote:

> 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
>>
>
>