[concurrency-interest] Thanks for the comments and suggestions re: CopyOnWrite wrappers

Morgan Conrad morganconrad at yahoo.com
Thu Dec 9 12:56:56 EST 2010

They were very constructive and useful.  Attempting to summarize.

1. Several suggestions to use existing classes, some of which are less familiar, 3rd party, etc.  Good info for the future.  Interestingly, none of these classes were wrappers.  IMO, there are some cases where a wrapper is more practical, so hopefully my code will prove useful if your underlying List or Map has strange behavior, or is difficult to upgrade cause it's tangled, ancient code.

2. A lot of comments to the effect of "these aren't really CopyOnWrite".  While, at a high level, they have many of the advantages and tradeoffs of CopyOnWrite (clean iteration, optimized for write-seldom iterate-often) it is absolutely true that they aren't really CopyOnWrite, and that may confuse (or create bugs for) users who expect that behavior.  I got one comment that these are really "concurrent iteration safe" wrappers.  I like it - it also makes issue #3 (below) more clear.  So I plan to change the name and make it more clear that these aren't true CopyOnWrite.  Besides, I like the "cis" abbreviation.  Just have to invent a companion class, "Totally Reliable Abstract Numeric Synchronizer".  (that's the first, and hopefully the last, organic chemistry joke I'll ever put on the internet)

3.  Many proposals to eliminate the synchronization blocks, especially for the reads, perhaps using atomics.  This is something to look into.  There's a case to be made for what I did:

a) simple, hopefully reliable
b) "Idiot proof" - the underlying Map need not be itself synchronized.  (in my case it wasn't)  If the underlying Map is not synchronized, you'll need a wrapper to make it so, losing the speed you are trying to gain.
c) Frankly, I seldom use atomics so I didn't think of it.

Now, one thing I might do is synchronize on the underlying Collection, not my wrapper.  As I understand, the JVM is pretty smart about synching on the same object twice, so this would enhance speed if the underlying Collection were itself synched.

I'll probably leave the non-synch atomic implementation as an "exercise for the reader".

Again, thanks for the comments.


More information about the Concurrency-interest mailing list