[concurrency-interest] Concurrency Wrappers

Doug Lea dl@cs.oswego.edu
Wed, 25 Jun 2003 19:06:41 -0400


Curt, thanks very much for your posts! Despite negative reactions to
your suggestions, they will lead to a couple of changes in JSR-166.

A naming issue that we hadn't dealt with well is to consistently
distinguish "concurrent" classes from "synchronized" ones. it took
a self-proclaimed non-expert to make us realize the problem here.

For example, Collections.synchronizedMap(new HashMap()) and Hashtable
are "synchronized" but the new j.u.c.ConcurrentHashMap is
"concurrent". A concurrent collection (among other kinds of classes)
is thread-safe, but not governed by a single exclusion lock. So, in
the particular case of ConcurrentHashMap, it safely permits any number
of concurrent reads as well as a tunable number of concurrent writes.
The main payoff is scalability -- performance remains good even when
the tables are read/written by many dozens of threads.  (Which is
absolutely not the case for Hashtable and synchronized-wrapped
HashMaps.) Also, while you can usually make a synchronized collection
from an unsynchronized one using a wrapper, concurrent collections
normally use completely different algorithms, so you need separate
classes.

Your posting brought to light that we haven't been very helpful in
communicating this distinction. But we will do some renamings (plus
documentation) to make it easier to figure out which collections are
designed for scalable concurrency by uniformly prefixing them with
"Concurrent". For example, LinkedQueue will become
ConcurrentLinkedQueue. (The BlockingQueues don't need such prefixing
since blocking implies multithreaded usage.)

(To anticipate follow-ups: Yes, we ARE considering introducing
ConcurrentArrayList and ConcurrentTreeMap classes, but under the
category of "stuff to consider after getting everything else in
JSR-166 ready for JDK1.5.)

-Doug