It says: "The function is NOT guaranteed to be applied once atomically only if the value is not present."
It's hard to parse this sentence, and it seems to me to make little sense since when the value is present, the function is not applied at all. IMO it would be better to remove the last part "only if the value is not present", making it equal to the corresponding sentence in compute() and computeIfPresent() Javadocs. _______________________________________________ Concurrency-interest mailing list [hidden email] http://cs.oswego.edu/mailman/listinfo/concurrency-interest |
Define "present" / "not present". In a concurrent setting the boolean outcome of the function does not imply anything about how it decided that. In particular, was it seen "not present", but lost the race to set the new value. Alex On Mon, 24 Feb 2020, 04:57 Roman Leventov via Concurrency-interest, <[hidden email]> wrote:
_______________________________________________ Concurrency-interest mailing list [hidden email] http://cs.oswego.edu/mailman/listinfo/concurrency-interest |
In reply to this post by JSR166 Concurrency mailing list
We tried to improve the docs for ConcurrentHashMap in https://hg.openjdk.java.net/jdk/jdk/rev/35bac2745d04 ConcurrentSkipListMap has a different spec but could also benefit from similar improvements. The key idea is that the ConcurrentHashMap "locks" an entry while a remapping function is called, but ConcurrentSkipListMap does not. But that's still not very clear. And we don't want to use any wording like "entry is locked". On Sun, Feb 23, 2020 at 8:57 PM Roman Leventov via Concurrency-interest <[hidden email]> wrote:
_______________________________________________ Concurrency-interest mailing list [hidden email] http://cs.oswego.edu/mailman/listinfo/concurrency-interest |
Free forum by Nabble | Edit this page |