[concurrency-interest] CopyOnWrite for Maps and other lists (not just ArrayList)

Neil Swingler neil at swingler.ch
Wed Dec 8 14:38:18 EST 2010

How about using one of the pure functional immutable collections out
there like pCollections or functional-java. If you need to synchronise
concurrent access you can do that using an AtomicObject.

- Neil

On Wed, 2010-12-08 at 11:09 -0800, Sangjin Lee wrote:
> 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...
> Sangjin
> 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
>         http://flyingspaniel.blogspot.com/2010/12/copyonwrite-wrappers.html
>         The Source Code is stored on a wiki at
>         http://flyingspaniel.wikidot.com/cow   (click on the files
>         link at the bottom)
>         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
>         HashMap.
>         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
>         classes.
>         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
>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list