[concurrency-interest] ConcurrentSkipListMap

Doug Lea dl at cs.oswego.edu
Thu Aug 17 13:16:36 EDT 2017


Thanks to Pedro Ramalhete for helping check that new CSLM doesn't alter
thread-safety properties. But while doing so, we noticed that the
existing javadocs for Object.equals, Comparable.compareTo, and
Comparator.compare at best only implicitly indicate their need for
thread safety, and that it's easy to come up with examples in CSLM,
ConcurrentHashMap, and other classes in which failure to comply
leads to crazy behavior.

This should not be news to anyone. But still, the equals, compareTo,
and compare javadocs should be explicit. Something along the lines of:


Object.java:

*** b/Object.java	2017-05-18 13:47:17.975768272 -0400
--- ./Object.java	2017-08-17 12:51:36.021851040 -0400
***************
*** 129,135 ****
       * <li>It is <i>consistent</i>: for any non-null reference values
!      *     {@code x} and {@code y}, multiple invocations of
!      *     {@code x.equals(y)} consistently return {@code true}
!      *     or consistently return {@code false}, provided no
!      *     information used in {@code equals} comparisons on the
!      *     objects is modified.
       * <li>For any non-null reference value {@code x},
--- 129,138 ----
       * <li>It is <i>consistent</i>: for any non-null reference values
!      *     {@code x} and {@code y}, multiple invocations of {@code
!      *     x.equals(y)} (possibly across multiple threads)
!      *     consistently return {@code true} or consistently return
!      *     {@code false}, provided no information used in {@code
!      *     equals} comparisons on the objects is modified. In
!      *     multithreaded programs, this can be guaranteed by ensuring
!      *     that all values used in computing equality are immutable or
!      *     are accessed under correct synchronization.
       * <li>For any non-null reference value {@code x},


Comparable.java:

*** b/Comparator.java	2017-05-18 13:47:39.301752902 -0400
--- ./Comparator.java	2017-08-17 13:05:15.702034642 -0400
***************
*** 91,92 ****
--- 91,99 ----
   *
+  * <p>As is the case for {@link Object#equals}, the {@code compare}
+  * method must be <em>consistent</em>: In the absence of modification,
+  * multiple invocations (possibly across multiple thread) have
+  * equivalent results. In multithreaded programs, this can be
+  * guaranteed by ensuring that all compared values are immutable or
+  * accessed under correct synchronization.
+  *
   * <p>Unlike {@code Comparable}, a comparator may optionally permit


Comparator.java:

*** b/Comparator.java	2017-05-18 13:47:39.301752902 -0400
--- ./Comparator.java	2017-08-17 13:05:15.702034642 -0400
***************
*** 91,92 ****
--- 91,99 ----
   *
+  * <p>As is the case for {@link Object#equals}, the {@code compare}
+  * method must be <em>consistent</em>: In the absence of modification,
+  * multiple invocations (possibly across multiple thread) have
+  * equivalent results. In multithreaded programs, this can be
+  * guaranteed by ensuring that all compared values are immutable or
+  * accessed under correct synchronization.
+  *
   * <p>Unlike {@code Comparable}, a comparator may optionally permit




More information about the Concurrency-interest mailing list