Re: [infinispan-dev] ClockService
On 1/29/13 6:45 PM, Manik Surtani wrote:
On 29 Jan 2013, at 17:17, Bela Ban <bban(a)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)