Re: ConcurrentHashMap and equality

--===============0745492260765349985==
Content-Type: multipart/alternative; boundary="0000000000004df41705daa46088"

--0000000000004df41705daa46088
Content-Type: text/plain; charset="UTF-8"

It is unfortunate then that affected users might be dependent on the
ordering of their equals statement due to a lack of symmetry. During
quiescing the property is broken by causing CHM.equals(Map.of(a, b)) and
Map.of(a, b).equals(CHM) to differ, since all non-concurrent JDK maps
inherit the size() check. If unintentionally depending on this then a small
refactoring would break behavior that might be hard to debug. Naively, I'd
consider this an implementation detail equivalent to parsing an unspecified
toString(), except less explicit in code as it is very sneaky. Of course
the performance difference probably doesn't warrant making a change, but
the possibility that someone might rely on this behavior is an
uncomfortable consideration.

On Sat, Mar 19, 2022 at 4:40 AM Doug Lea via Concurrency-interest <
[email protected]> wrote:

>
> On 3/13/22 18:51, Benjamin Manes via Concurrency-interest wrote:
> > 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?
>
> This seems reasonable, but there is a tiny chance of incompatibility to
> make this change. The count is only quiescently accurate, and is updated
> after modifications. If there is a call while quiescing, then the
> elements may be stable before the count is. (Which was the original
> reason for not checking count first.) I'm not sure that the very rare
> possibility of a detectable difference matters, but CHM is used enough
> that someone might be unknowingly relying on this.
>
> -Doug
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

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

<div dir=3D"ltr">It is unfortunate then that affected users might be depend=
ent on the ordering of their equals statement due to a lack of symmetry. Du=
ring quiescing=C2=A0the property is broken by causing CHM.equals(Map.of(a, =
b)) and Map.of(a, b).equals(CHM) to differ, since all non-concurrent JDK ma=
ps inherit the size() check. If unintentionally depending on this then a sm=
all refactoring would break behavior that might be hard to debug. Naively, =
I&#39;d consider this an implementation detail equivalent to parsing an uns=
pecified toString(), except less explicit in code as it is very sneaky. Of =
course the performance difference probably doesn&#39;t warrant=C2=A0making =
a change, but the possibility=C2=A0that someone might rely on this behavior=
 is an uncomfortable consideration.</div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Sat, Mar 19, 2022 at 4:40 AM Doug Lea=
 via Concurrency-interest &lt;<a href=3D"mailto:[email protected]=
ego.edu">[email protected]</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><br>
On 3/13/22 18:51, Benjamin Manes via Concurrency-interest wrote:<br>
&gt; The equality contract for Map is defined as having the same mappings <=
br>
&gt; in their entrySet views. The AbstractMap and AbstractSet <br>
&gt; implementations include a size() prescreen, which is typically an <br>
&gt; immediate operation. The concurrent maps don&#39;t, though, and I am <=
br>
&gt; wondering if this is a missed opportunity. The consistency property <b=
r>
&gt; already dictates that the comparison is deterministic only if neither =
<br>
&gt; object or its parts are modified between invocations. Therefore the <b=
r>
&gt; method&#39;s documentation that equality may be=C2=A0misleading in=C2=
=A0the face of <br>
&gt; concurrency is simply=C2=A0a reminder of that fact. Since the size che=
ck <br>
&gt; might be performed regardless by an AbstractMap-based implementation <=
br>
&gt; (e.g. HashMap), then by symmetry it would imply that adding this <br>
&gt; prescreen would be an acceptable optimization. Does that seem <br>
&gt; reasonable or is there an aspect that I am forgetting?<br>
<br>
This seems reasonable, but there is a tiny chance of incompatibility to <br=
>
make this change. The count is only quiescently accurate, and is updated <b=
r>
after modifications. If there is a call while quiescing, then the <br>
elements may be stable before the count is. (Which was the original <br>
reason for not checking count first.) I&#39;m not sure that the very rare <=
br>
possibility of a detectable difference matters, but CHM is used enough <br>
that someone might be unknowingly relying on this.<br>
<br>
-Doug<br>
<br>
<br>
<br>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Con=
[email protected]</a><br>
<a href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel=
=3D"noreferrer" target=3D"_blank">http://cs.oswego.edu/mailman/listinfo/con=
currency-interest</a><br>
</blockquote></div>

--0000000000004df41705daa46088--

--===============0745492260765349985==
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

--===============0745492260765349985==--