Wikipedia

User:RyeTheCat/sandbox

< User:RyeTheCat


The Java programming language's Java Collections Framework version 1.5 and later defines and implements both the original regular single-threaded Maps, and it added thread-safe Maps implementing the java.util.ConcurrentMapinterface among other concurrent interfaces. In Java 1.6, the java.util.NavigableMap interface was added, extending java.util.SortedMap, and the java.util.ConcurrentNavigableMap interface was added as a subinterface combination.

Java Map Interfaces

edit

The version 1.6 Map interface diagram has the shape below. Sets can be considered sub-cases of corresponding Maps in which the values are always a particular constant which can be ignored, although the Set API uses corresponding but differently named methods. At the bottom is the java.util.concurrent.ConcurrentNavigableMap, which is a multiple-inheritance.

Concurrent modification problem

edit

One problem solved by the Java 1.5 java.util.concurrent package is that of concurrent modification. The collection classes it provides may be reliably used by multiple Threads.

All Thread-shared non-concurrent Maps and other collections need to use some form of explicit locking such as native synchronization in order to prevent concurrent modification, or else there must be a way to prove from the program logic that concurrent modification cannot occur. Concurrent modification of a Map by multiple Threads will sometimes destroy the internal consistency of the data structures inside the Map, leading to bugs which manifest rarely or unpredictably, and which are difficult to detect and fix. Also, concurrent modification by one Thread with read access by another Thread or Threads will sometimes give unpredictable results to the reader, although the Map's internal consistency will not be destroyed. Using external program logic to prevent concurrent modification increases code complexity and creates an unpredictable risk of errors in existing and future code, although it enables non-concurrent Collections to be used. However, either locks or program logic cannot coordinate external threads which may come in contact with the Collection.

Modification counters

edit

In order to help with the concurrent modification problem, the non-concurrent Map implementations and other Collections use internal modification counters which are consulted before and after a read to watch for changes: the writers increment the modification counters. A concurrent modification is supposed to be detected by this mechanism, throwing a java.util.ConcurrentModificationException, but it is not guaranteed to occur in all cases and should not be relied on. The counter maintenance is also a performance reducer. For performance reasons, the counters are not volatile, so it is not guaranteed that changes to them will be propagated between Threads.

Collections.SynchronizedMap()

edit

One solution to the concurrent modification problem is using a particular wrapper class provided by a factory in Collections: public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m) which wraps an existing non-thread-safe Map with methods that synchronize on an internal mutex. There are also wrappers for the other kinds of Collections. This is a partial solution, because it is still possible that the underlying Map can be accessed inadvertently by Threads which keep or obtain unwrapped references. Also, all Collections implement the java.lang.Iterable but the synchronized-wrapped Maps and other wrapped Collections do not provide synchronized iterators, so the synchronization is left to the client code, which is slow and error prone and not possible to expect to be duplicated by other consumers of the synchronized Map. The entire duration of the iteration must be protected as well. Furthermore, a Map which is wrapped twice in different places will have different internal mutex Objects on which the synchronizations operate, allowing overlap. Of course the delegation is a performance reducer, but modern Just-in-Time compilers often inline heavily, limiting the performance reduction. The synchronization of the Iteration is recommended as follows, however, this synchronizes on the wrapper rather than on the internal mutex, allowing overlap: 

   Map<String, String> m = Collections.synchronizedMap(map);
         ...
   synchronized (m) {
       for (String s : m) {
           // some possibly long operation executed possibly 
           // many times, delaying all other accesses
       }
   }

Native synchronization

edit

Any Map can be used safely in a multi-threaded system by ensuring that all accesses to it are handled by the Java synchronization mechanism: 

   Map<String, String> map = new HashMap<String, String>();
   ...
   // Thread A
   // Use the map itself as the lock. Any agreed object can be used instead.
   synchronized(map) {
      map.put("key","value");
   }
   ..
   // Thread B
   synchronized (map) {
       String result = map.get("key");
        ...
    }
   ...
   // Thread C
   synchronized (map) {
       for (Entry<String, String> s : map.entrySet()) {
           /*
            * Some possibly slow operation, delaying all other supposedly fast operations. 
            * Synchronization on individual iterations is not possible.
            */ 
           ...
       }
   }

ReentrantReadWriteLock

edit

The code using a java.util.concurrent.ReentrantReadWriteLock is similar to that for native synchronization. However, for safety, the locks should be used in a try/finally block so that early exit such as Exception throwing or break/continue will be sure to pass through the unlock. This technique is better than using synchronization because reads can overlap each other, however for simplicity a java.util.concurrent.ReentrantLock can be used instead, which makes no distinction. Convoys are still possible, and there is a new issue in deciding how to prioritize the writes with respect to the reads. More operations on the locks are possible than with synchronization, such as tryLock() and tryLock(long timeout, TimeUnit unit). 

   final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
   final ReadLock readLock = lock.readLock();
   final WriteLock writeLock = lock.writeLock();
   ..
   // Thread A
   try {
       writeLock.lock();
       ...
   } finally {
       writeLock.unlock();
   }
   ...
   // Thread B
   try {
       readLock.lock();
       ..
   } finally {
       readLock.unlock();
   }

Convoys

edit

Mutual exclusion has a 'convoy' problem, in which threads may pile up on a lock, causing the JVM to need to maintain expensive queues of waiters and to 'park' the waiting threads. It is expensive to park and unpark a thread, and a slow context switch may occur. Context switches require from microseconds to milliseconds, while the Map's own basic operations normally take nanoseconds. Performance can drop to a small fraction of a single Threads' throughput. When there is no or little contention for the lock, there is little performance impact, however, except for the lock's contention test. Modern JVMs will inline most of the lock code, reducing it to only a few instructions, keeping the no-contention case very fast. Reentrant techniques like native synchronization or java.util.concurrent.ReentrantReadWriteLock however have extra performance-reducing baggage in the maintenance of the reentrancy depth, affecting the no-contention case as well.

Multiple cores

edit

Mutual exclusion solutions fail to take advantage of all of the computing power of a multiple-core system, because only one Thread is allowed inside the Map code at a time. The implementations of the particular concurrent Maps provided by the Java Collections Framework and others sometimes take advantage of multiple cores using Lock-Free programming techniques. Lock-free techniques use the compareAndSet() intrinsic method available on many of the Java classes such as AtomicInteger to do updates of some Map-internal structures atomically. The compareAndSet() primitive is augmented in the JCF classes by native code that can do compareAndSet on special internal parts of some Objects for some algorithms (using 'unsafe' access). The techniques are complex, relying often on the rules of inter-thread communication provided by volatile variables, the happens-before relation, special kinds of lock-free 'retry loops' (which are not like spin locks in that they always produce progress).

Smooth access

edit

Yet another problem with mutual exclusion approaches is that the assumption of complete atomicity made by some single-threaded code creates sporadic delays between threads. In particular, Iterators and bulk operations like putAll() and others can take a length of time proportional to the Map size, possibly locking out access by other Threads that expect predictable short delays for non-bulk operations. For example, a multi-threaded web server cannot allow some responses to be delayed by long-running iterations of other threads executing other requests that are searching for a particular value.

Weak consistency

edit

The java.util.concurrency packages' solution to the concurrent modification problem, the convoy problem, the smooth access problem, and the multi-core problem includes an architectural choice called weak consistency. Weak consistency allows, for example, the contents of a ConcurrentMap to change during an iteration of it. So, for example, a Map containing two entries that are inter-dependent may be seen in an inconsistent way by a reader Thread during modification by another Thread. An update that is supposed to change the key of an Entry (k1,v) to an Entry (k2,v) atomically would need to do a remove(k1) and then a put(k2, v), while an iteration might miss the entry or see it in two places. There are some atomic operations provided to allow atomicity of certain updates, however: the replace(K, V1, V2) will test for the existence of V1 in the Entry identified by K and only if found, then the V1 is replaced by V2 atomically. This atomicity is very important for some multi-threaded use cases, but is not related to the weak-consistency constraint.

ConcurrentHashMap

edit

For unordered access as defined in the java.util.Map interface, the java.util.concurrent.ConcurrentHashMap implements java.util.concurrent.ConcurrentMap. The mechanism is a hash access to a hash table with zoned locks. There is an assumption that there is a relatively small amount of modification compared to reading.

ConcurrentSkipListMap

edit

For ordered access as defined by the java.util.NavigableMap interface, java.util.concurrent.ConcurrentSkipListMap implements java.util.concurrent.ConcurrentMap and also java.util.concurrent.ConcurrentNavigableMap. It is a Skip list which uses Lock-free techniques.

See also

edit

References

edit
edit
 
The Wikibook Java Programming has a page on the topic of: Collections
Retrieved from "https://en.wikipedia.org/w/index.php?title=User:RyeTheCat/sandbox&oldid=721792022"