title: ConcurrentHashMap: what's the point in locking updates only?
body: <p>I always thought that <code>ConcurrentHashMap</code> and similar classes (which maintain synchronized updates and don't synchronize reads) did a very useful and intuitive thing: they did not lock reads and lock all functionality on updates. And a strategy like that does keep all things consistent.</p>
  
  <p>But I read the documentation carefully, and opened the implementation of <code>ConcurrentHashMap</code>, and as I understand now, it <em>does not</em> block reads when another thread is performing updates. And if one thread starts doing <code>putAll(hugeCollection)</code> and another thread repeats <code>contains(theSameObjectForAllCalls)</code> at the same time then it's more then likely that the second thread gets different results while <code>putAll</code> is still working.</p>
  
  <p>Here is the related part from the docs:</p>
  
  <blockquote>
    <p>For aggregate operations such as
    putAll and clear, concurrent
    retrievals may reflect insertion or
    removal of only some entries.</p>
  </blockquote>
  
  <p>Another interesting thing is that:</p>
  
  <blockquote>
    <p>Retrievals reflect the results of the
    most recently completed update
    operations holding upon their onset.</p>
  </blockquote>
  
  <p>This works not due to some locking, but because a new object is first being added and only after that objects counter is incremented and the object becomes <em>visible</em> for read operations.</p>
  
  <p>So, what's the whole point of locking updates?</p>