[infinispan-dev] ClockService

[Bela Ban]

On 1/29/13 6:45 PM, Manik Surtani wrote:
> On 29 Jan 2013, at 17:17, Bela Ban <bban at redhat.com> 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)