ConcurrentHashMap and equality

--===============4595945156167872751==
Content-Type: multipart/alternative; boundary="000000000000457fe905da216a1f"

--000000000000457fe905da216a1f
Content-Type: text/plain; charset="UTF-8"

The equality contract for Map is defined as having the same mappings in
their entrySet views. The AbstractMap and AbstractSet implementations
include a size() prescreen, which is typically an immediate operation. The
concurrent maps don't, though, and I am wondering if this is a missed
opportunity. The consistency property already dictates that the comparison
is deterministic only if neither object or its parts are modified between
invocations. Therefore the method's documentation that equality may
be misleading in the face of concurrency is simply a reminder of that fact.
Since the size check might be performed regardless by an AbstractMap-based
implementation (e.g. HashMap), then by symmetry it would imply that adding
this prescreen would be an acceptable optimization. Does that seem
reasonable or is there an aspect that I am forgetting?

--000000000000457fe905da216a1f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>The equality contract for Map is defined as having th=
e same mappings in their entrySet views. The AbstractMap and AbstractSet im=
plementations include a size() prescreen, which is typically an immediate o=
peration. The concurrent maps don&#39;t, though, and I am wondering if this=
 is a missed opportunity. The consistency property already dictates that th=
e comparison is deterministic only if neither object or its parts are modif=
ied between invocations. Therefore the method&#39;s documentation that equa=
lity may be=C2=A0misleading in=C2=A0the face of concurrency is simply=C2=A0=
a reminder of that fact. Since the size check might be performed regardless=
 by an AbstractMap-based implementation (e.g. HashMap), then by symmetry it=
 would imply that adding this prescreen would be an acceptable optimization=
. Does that seem reasonable or is there an aspect that I am forgetting?<br>=
</div></div>

--000000000000457fe905da216a1f--

--===============4595945156167872751==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--===============4595945156167872751==--