[concurrency-interest] Timestamps-based ConcurrentMap

David Holmes dcholmes at optusnet.com.au
Fri Mar 10 20:21:51 EST 2006

Jean Morissette writes:
> Each entry could have two timestamps, one for its creation and one set
> at its removal. Removed entries would remain in the map until there is
> no iterator that can see them, after which they would be (lazily?)
> removed.

They could, but now you are adding additional housekeeping and coordination
between the iterators and the map.

> In my scenario, there is as mush map update (put/remove) than querying
> (iterator) operations. Also, the size of these map can be really big.
> So, using a copy strategy to create a snapshot seems costly: it would
> involve a lot of copying. What do you think?

At this stage I'd ask exactly why you need an iterator that can be shared
amongst threads. :)

The desired semantics seem to be leading you into a no-win situation.
Ultimately you will have to pay for it somewhere.

David Holmes

More information about the Concurrency-interest mailing list