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