[infinispan-dev] [Discussion] TimeService implementation

[Sanne Grinovero]

On 29 April 2013 18:04, Pedro Ruivo <pedro at infinispan.org> wrote:
>
> On 04/29/2013 05:53 PM, Mircea Markus wrote:
>>
>> On 29 Apr 2013, at 17:34, Pedro Ruivo wrote:
>>
>>> Hi,
>>>
>>> The TimeService interface is going to replace all the System.nanoTime()
>>> and System.currentTimeMillis() in the code and it will allow to replace
>>> in the test suite in order to provide a better control over the time
>>> dependent code (if needed).
>>>
>>> The objective of this email is to discuss possible implementation and
>>> interface that will cover the needs of everybody (or at least try it).
>>> Later I'll create a JIRA and start the implementation (except if someone
>>> really wants to implement it :P)
>>>
>>> * Interface:
>>>
>>> //return the current time in nanoseconds and milliseconds respectively
>>> long nowNanos()
>>> long nowMillis()
>> What about time() and wallClockTime() with overloaded methods time(TimeUnit) and wallClockTime(TimeUnit)?
>
> what is the semantic of wallClockTime()? I'm assuming that time()
> returns the current time in nanoseconds...

There are at least two ways to use a Clock service, as there are
different methods to get the "time" and different concepts of "time"
depending on what your purpose is.

For example you should never use two invocations of
System.currentTimeMillis() to measure time intervals; it's generally
less accurate but also it is affected by system clock changes, while
nanoTime() is not. The underlying system calls are different, and
depending on the platform the precision guarantees are different and
in some cases the different precision guarantee has a significant
impact on runtime performance of the invocation, for example not all
can be JIT optimized.

Most of the time we want to use nanoTime(), for example for metrics,
but its precision is valid only in the scope of the machine it's
executed on, so this value is meaningless for something which needs to
be shared with other nodes.. complex, and we might want to switch
implementation for certain use cases depending on the cluster mode.

In other words: the method invoker needs to make it very clear what
its goal is, what it wants to do with the requested "long" as it's not
just a simple universally valid primitive.