[concurrency-interest] Timestamps-based ConcurrentMap

Bob Lee crazybob at crazybob.org
Sat Mar 11 10:58:55 EST 2006

On 3/11/06, David Holmes <dcholmes at optusnet.com.au> wrote:
> That is still an interesting requirement if the map is in use when the
> iterator is created, as there are potential races adding or removing
> elements.
> As there is no way to make an atomic snapshot then you will have to have
> some way of telling when each entry was added and removed from the map. Your
> timestamps seem the only option - albeit a complicated one.

Actually, first, is it OK for additions/removals during the actual
creation (but not after)? If so, my original solution will work.

If not, in lieu of timestamps, you can decorate your map and record
undo objects. At the point where you want your "snapshot," you ask the
map for an undo version (this will be an index into the list of undo
objects, the map will start recording them if it isn't already). Next,
create your copy by iterating over the map and take another undo
version (this also tells the map you're done which means it may be
able to stop recording). Now execute the undo objects against your map
copy and you should have a snapshot of the map at the point your took
the first undo version.

As this is a concurrent map, entries can be added/removed at the time
you take the actual snapshot (which means the snapshot would include
the change). Is this acceptable?

The neat thing about this is you can implement it as a decorator and
it will work with any concurrent map (i.e. no hacking the internals of


More information about the Concurrency-interest mailing list