[infinispan-dev] [Discussion] TimeService implementation

[Galder Zamarreño]

On May 1, 2013, at 5:04 PM, Sanne Grinovero <sanne at infinispan.org> wrote:

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

^ Can you explain further why you'd want a different implementation 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.
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org