On 1/29/13 6:45 PM, Manik Surtani wrote: > On 29 Jan 2013, at 17:17, Bela Ban <[email protected]> wrote: > >> On 1/29/13 5:25 PM, Sanne Grinovero wrote: >>> Glad you started work on that :) >>> >>> Any currentTimeMillis() even today will blow away your cache line and >>> probably trigger a context switch. >> I understand the context switch (in general, it's not recommended anyway >> to invoke a system call in synchronized code), but I fail to see why >> this would blow the cache line. Are you referring to the cached Date >> value here ? > No, if you have a separate maint thread that updates a reusable > currentTimeMillis value. > > Do you use nanoTime() a lot then? Because that too is inefficient (as per > the Oracle blog) ...
Define inefficient ! I'm sure we're talking about nanosec / microsec ranges here, so 3% faster won't cut it for me. If you contrast that to my current work, where I try to deliver a batch of N messages and therefore can skip N-1 lock acquitions/releases for M protocols, then the latter wins... I still think a clock service is interesting, but for different reasons. As Sanne mentioned in Palma, it would be interesting to 'control' time, e.g. deliver 2 messages at the same time, or even go backwards in time. In the case of JGroups, we could use a clock service to screw up message reception (e.g. in testing) and therefore to test the correctness of some protocols. -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
