My dive into the specifics (of e.g. the volatile load) probably confused
the issue. Nothing on either side actually establishes a happens-before
relationship between e.g. seg.count write in put() in Thread1 and a
seg.count read in size() in Thread2... It's up to an [optional] something
else to
Thanks for the detailed reply.
Yes, JDK code is special. From an ordering perspective, the segmentAt()
does a volatile read and ensures visibility.
However from happen-before perspective, I cannot find happen-before
relation between seg.count read action with seg.count write action.
thread
In the presence of concurrent modification, size() can be stale by
definition, since the modification could occur between size() establishing
a notion of what size is and your next operation that might assume the size
is somehow representative of the current state of the table.
When no concurre
"...useful only when a map is not undergoing concurrent updates in other
threads..."
The size() method sums the segment field "modCount" twice and compares the
result to ensure no concurrent updates in other threads.
If there's concurrent updates, the size() method resort to locking
segments. S
* Bear in mind that the results of aggregate status methods including
* {@code size}, {@code isEmpty}, and {@code containsValue} are typically
* useful only when a map is not undergoing concurrent updates in other threads.
* Otherwise the results of these methods reflect transient states
* that may
