[concurrency-interest] CopyOnWrite for Maps and other lists (not just ArrayList)
sjlee0 at gmail.com
Wed Dec 8 14:09:28 EST 2010
One of the key value propositions of the copy-on-write idea in the
traditional sense is to optimize for the read performance. If I understand
correctly, the basic idea is to copy and replace the underlying collection
every time write is performed. Thus, all read access would simply (and
concurrently) access the collection without synchronization as the
underlying collection is "read-only" in a sense.
It seems in your case all methods are synchronized (and you state as much in
the javadoc), so all read access is also synchronized and serialized. It
looks like iteration can be done concurrently and safely, but it doesn't
seem to realize the full (and main) benefit of the copy-on-write pattern...
On Wed, Dec 8, 2010 at 9:30 AM, Morgan Conrad <morganconrad at yahoo.com>wrote:
> Thanks for the interest Chris!
> A blog post, with links to the code, is at
> The Source Code is stored on a wiki at
> http://flyingspaniel.wikidot.com/cow (click on the files link at the
> I took a brief look at the org.apache.mina.util.CopyOnWriteMap. It uses a
> HashMap underneath, and really does a copy on write of the underlying
> As mentioned in the blog post, strictly speaking, I do not "copy on write".
> I effectively "copy the iterators on write". In this way it supports (at
> least theoretically) any type of underlying List or Map, such as a TreeMap,
> where the order of iteration is much different than a HashMap, or some
> user's ReallyWeirdCustomCollection that has unusual rules for null keys or
> values, a custom Comparator, etc...
> I believe the code to be reasonably thread-safe but can easily imagine
> members of this interest group finding holes or proposing improvements. :-)
> I found it ironic/interesting that where java.util.concurrency uses actual
> classes for, say, CopyOnWriteArray, my code provides wrappers. And, while
> standard java.util.Collections provides wrappers for unmodifiable
> collections, my code, mainly to be different and provide an alternative, has
> Thanks for your interest, and I hope the code or idea proves useful to
> somebody. As things turned out, we didn't need to use this code, so it
> would be nice if somebody got some use out of it.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest