[concurrency-interest] Paper-> Exposing Non-Atomic Methods of Concurrent Objects

Doug Lea dl at cs.oswego.edu
Thu Jul 6 10:53:10 EDT 2017

On 07/06/2017 09:37 AM, Kimo Crossman wrote:
> https://arxiv.org/abs/1706.09305
>   Exposing Non-Atomic Methods of Concurrent Objects
> Michael Emmi,  Constantin Enea

This tool seems useful (running it before release would have
picked up a fixed bug). The other non-atomicities reported
are expected, but show that people either don't read our
package-level documentation, or don't always bear it in mind.
Here's what it currently says. We should probably improve it, and/or
replicate some of it in particular classes. Suggestions welcome.

Pasting from ...

Concurrent Collections
Besides Queues, this package supplies Collection implementations
designed for use in multithreaded contexts: ConcurrentHashMap,
ConcurrentSkipListMap, ConcurrentSkipListSet, CopyOnWriteArrayList, and
CopyOnWriteArraySet. When many threads are expected to access a given
collection, a ConcurrentHashMap is normally preferable to a synchronized
HashMap, and a ConcurrentSkipListMap is normally preferable to a
synchronized TreeMap. A CopyOnWriteArrayList is preferable to a
synchronized ArrayList when the expected number of reads and traversals
greatly outnumber the number of updates to a list.

The "Concurrent" prefix used with some classes in this package is a
shorthand indicating several differences from similar "synchronized"
classes. For example java.util.Hashtable and
Collections.synchronizedMap(new HashMap()) are synchronized. But
ConcurrentHashMap is "concurrent". A concurrent collection is
thread-safe, but not governed by a single exclusion lock. In the
particular case of ConcurrentHashMap, it safely permits any number of
concurrent reads as well as a large number of concurrent writes.
"Synchronized" classes can be useful when you need to prevent all access
to a collection via a single lock, at the expense of poorer scalability.
In other cases in which multiple threads are expected to access a common
collection, "concurrent" versions are normally preferable. And
unsynchronized collections are preferable when either collections are
unshared, or are accessible only when holding other locks.

Most concurrent Collection implementations (including most Queues) also
differ from the usual java.util conventions in that their Iterators and
Spliterators provide weakly consistent rather than fast-fail traversal:

    they may proceed concurrently with other operations
    they will never throw ConcurrentModificationException
    they are guaranteed to traverse elements as they existed upon
construction exactly once, and may (but are not guaranteed to) reflect
any modifications subsequent to construction.

More information about the Concurrency-interest mailing list