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 <hbo...@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 <marti...@google.com> > wrote: > >> >> >> On Sun, Aug 20, 2017 at 9:53 PM, David Holmes <david.hol...@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.hol...@oracle.com >>>> <mailto:david.hol...@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 >> > >
