Package org.sosy_lab.common.collect

Class CopyOnWriteSortedMap<K,V extends @Nullable Object>

java.lang.Object
com.google.common.collect.ForwardingObject
com.google.common.collect.ForwardingMap<K,V>
com.google.common.collect.ForwardingSortedMap<K,V>
com.google.common.collect.ForwardingNavigableMap<K,V>
org.sosy_lab.common.collect.CopyOnWriteSortedMap<K,V>
Type Parameters:
K - The type of keys.
V - The type of values.
All Implemented Interfaces:
Map<K,V>, NavigableMap<K,V>, SortedMap<K,V>
public final class CopyOnWriteSortedMap<K,V extends @Nullable Object> extends ForwardingNavigableMap<K,V>
This is a map implementation that uses copy-on-write behavior. This may be a good fit when you want to keep old snapshots of the map while modifying it. Through the use of a PersistentMap backend, snapshots and modifying operations are both cheap (O(1) for the former, usually O(log n) for the latter).

There are two usage patterns for this map. First, you can keep one instance of of the map which you modify, and eventually call getSnapshot() to take immutable snapshots. Second, you can use an instance of the map and create copies of it with the copyOf(CopyOnWriteSortedMap) method (these copies are O(1)). Then you can modify both the old and the new instance, but modifications to one of it won't be reflected by the other.

All collection views returned my methods of this map are live views and change if this map is modified. However, they currently do not support any modifying operations. All iterators produced by the collection views iterate over an immutable snapshot of the map taken at iterator creation time and thus do not reflect intermediate changes to the map. The iterators also don't support the Iterator.remove() method. Thus it is safe to iterate over the map while changing it.

This implementation is thread-safe and lock free, but does not guarantee freedom of starvation. Bulk operations are not atomic.