Aleksey Shipilev wrote:
It would really help if you list what problems weakNanoTime is
supposed to solve.
I was talking to Martin about this idea recently so I'll take a shot
at describing why it's appealing to me (with the usual disclaimer
that I know I'm much less of an expert than most other folks here).
The main case I'm interested in is handling timeout calculations in
concurrent operations. The usual case should be that the operation
succeeds without timing out, and if it _does_ time out it's often
after waiting several seconds or minutes, in which case being off
by, say, a few microseconds is not a big deal.
Given those assumptions, we really want the usual case (success) to
be as fast as possible, and especially not to impose any additional
synchronization or volatile accesses. Since strict monotonicity
requires checking some kind of centrally synchronized clock state,
it fails that use case.
Furthermore, in this particular use case, it's trivial to have the
appearance of monotonicity _within_ a particular operation: Just
keep a local variable with the last time seen, and only update it if
the next time seen is greater than the last time seen. No extra
synchronization is required.
The semantics I'm imagining would be for a very fast timer that is
_usually_ monotonic, as long as the current thread stays on one
processor, with occasional blips when switching between processors.
We would still want those blips to be as small as practically
achievable, so I guess there would still have to be some occasional
synchronization to keep the fast timer within some tolerance of the
central system clock.
The way I see it, good concurrency semantics are about acknowledging
the reality of the hardware, and a strictly monotonic clock is
simply not the reality of the hardware when there's more than one
processor involved.
Actually, come to think of it, given an underlying non-monotonic
timer, the weakNanoTime method could easily provide monotonicity on
a per-thread basis without any synchronization overhead. That would
mean most concurrent code wouldn't even have to change to become
tolerant of non-monotonicity. It would just have to be made really
clear to users that different threads might see timer values out of
order relative to each other, though still within some best-effort
tolerance.
Cheers,
Justin
