RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads
hboehm at google.com
Wed Aug 23 04:21:10 UTC 2017
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>
> On Sun, Aug 20, 2017 at 9:53 PM, David Holmes <david.holmes at oracle.com>
>> 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
>>> 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"
>> 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
> Before we fixed
> 8065372: Object.wait(ms, ns) timeout returns early
> returning early was unacceptably common
More information about the core-libs-dev