<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 2010-02-03, at 2:42 PM, Bryan Thompson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<div dir="ltr" align="left"><font face="Courier New" color="#0000ff" size="4"><span class="537343119-03022010">Vladimir,</span></font></div>
<div dir="ltr" align="left"><font face="Courier New" color="#0000ff" size="4"><span class="537343119-03022010"></span></font> </div>
<div dir="ltr" align="left"><font face="Courier New" color="#0000ff" size="4"><span class="537343119-03022010">
<div dir="ltr" align="left"><font face="Courier New" color="#0000ff" size="4"><span class="537343119-03022010">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?</span></font></div></span></font></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"><div dir="ltr" align="left"><font face="Courier New" color="#0000ff" size="4"><span class="537343119-03022010"><br>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.</span></font></div></div></blockquote><div><br></div><div><br></div><br><blockquote type="cite"><div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<div dir="ltr" align="left"><font face="Courier New" color="#0000ff" size="4"><span class="537343119-03022010"></span></font> </div>
<div dir="ltr" align="left"><font face="Courier New" color="#0000ff" size="4"><span class="537343119-03022010">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.</span></font></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<div dir="ltr" align="left"><font face="Courier New" color="#0000ff" size="4"><span class="537343119-03022010"></span></font> </div>
<div dir="ltr" align="left"><font face="Courier New" color="#0000ff" size="4"><span class="537343119-03022010">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.</span></font></div></div></blockquote><br></div><div>Yes, I think we will try both approaches anyway. Should not be to hard to do this, a few days of work.</div><div><br></div><div>Regards,</div><div>Vladimir</div><div><br></div><div><br></div></body></html>