[infinispan-dev] Lock amortization preliminary performance numbers

[Vladimir Blagojevic]

On 2010-02-03, at 2:42 PM, Bryan Thompson wrote:

> Vladimir,
>  
> So, you wind up with per-segment LRU orderings then, not global?  When you batch through, it is from the per-segment accessQueue to the per-segment LRU, right?

Exactly, it is all per segment. The idea is that eviction precision overall will not deteriorate if we do everything per segment. This is not a fact just a heuristic that needs to be verified. Otherwise, we have to fall back to shared pool solution you mentioned.

> 
> I have recently been bitten by non-blocking constructions which fail under high concurrency.  For example, I was using AtomicLong for a performance counter -- with disastrous results.  Under high contention, it winds up attempting to CAS without a change in its precondition, and failing and retrying again and again to get through the race.  This actually became the #1 hot spot in the code with an active thread pool.



>  
> So, I am very strongly in favor of using non-thread safe data structures under conditions where you know that you have single threaded access rather than "non-blocking" data structured.  For example, it might be cheaper to make the accessQueue a straight array or a ring buffer that was not thread safe and to use the segment lock to guard it.

Generally agree with you. Lets see if we can prove that BCHM does not work and I'll happily fall back to such a solution.

>  
> Maybe the better design is to explicitly manage the threads with access to the DataContainer and use thread-locals.  That would be both non-blocking (until the updates are batches) and would avoid the possibility of high concurrency CAS spins.

Yes, I think we will try both approaches anyway. Should not be to hard to do this, a few days of work.

Regards,
Vladimir


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100203/ee042fd6/attachment-0002.html