So, there is a concurrent hashmap in Java, the advantage of which is not to lock down the whole hash table, but only portions of it. I was wondering whether there was such a construction for arrays. Particularly when an array is being resized locking down the whole array is not desirable, especially in real time applications. Anything out there?
3
-
4You can't resize arrays in Java, just copy the elements into another different sized array.Marcelo– Marcelo2011-07-25 19:43:56 +00:00Commented Jul 25, 2011 at 19:43
-
Yes, I know. But the time it takes to create a new array and copy contents will have to be done by one thread, which, if the array is large makes things quite undesirable.delmet– delmet2011-07-25 20:05:52 +00:00Commented Jul 25, 2011 at 20:05
-
Instead of resizing you could use an array of arrays: no need for copy, just append a new segment if it gets too big. See github.com/graphhopper/graphhopper/blob/0.7/core/src/main/java/… and for integer it should be safe to write and read one value from multiple threads. Furthermore see this ConcurrentDoublyLinkedList java2s.com/Code/Java/Collections-Data-Structure/…Karussell– Karussell2016-08-30 22:54:07 +00:00Commented Aug 30, 2016 at 22:54
Add a comment
|
4 Answers
There is AtomicIntegerArray (and the similar AtomicReferenceArray) that may fit your description. But as noted by Marcelo - you can't resize arrays. So you only get concurrent safety without the need to explicitly lock (on) the entire array.
An array ... in which elements may be updated atomically
2 Comments
Andrzej Doyle
To what extent is the
AtomicIntegerArray different from AtomicInteger[] though? In particular, does e.g. AtomicIntegerArray.compareAndSet have different semantics to calling get(i).compareAndSet on an AtomicInteger[]? The Javadocs don't seem to propose any, which makes this look like merely a shorter syntax.
Bozho
I guess that another thread can replace the value at the given position, thus making compareAndSet happen on an object that is no longer in the array
Java 6 also adds an interesting collection called ConcurrentSkipListSet
...average log(n) time cost for thecontains, add, andremoveoperations and their variants. Insertion, removal, and access operations safely execute concurrently by multiple threads. Iterators are weakly consistent, returning elements reflecting the state of the set at some point at or since the creation of the iterator. They do not throw ConcurrentModificationException, and may proceed concurrently with other operations...
2 Comments
You can always use one of these:
java.util.Collections.synchronizedList(List<T> list)java.util.Collections.synchronizedCollection(Collection<T> collection)java.util.Collections.synchronizedSet(Set<T> set)
Your requirements aren't clear. Perhaps the java.util.collections copy-on-write list or set will do, too.
2 Comments
Parvez
This will lock the whole object and OP was asking for an equivalent of ConcurrentHashMap for array.
Parvez
I understand it is an old thread but I encountered this while I was looking for something and I thought it is better to highlight. I am sorry but I don't think this is useless. I neither downvote you nor had any other (hidden) intentions.
The closest thing in the standard library is the CopyOnWriteArrayList. That's 'concurrent' in the sense that there is no lock, and so not contention, for readers; however, access for writers is serialized, and is very expensive. The tradeoff is a bit sharper than for the concurrent hashmap: reads are really cheap, but writes are really expensive.
It seems like it might be possible to write a list implementation which used the striped lock strategy of the concurrent hashmap for single-element, size-preserving operations like get and set (and perhaps add to the end of the list), but the copy-on-write strategy for size-altering operations like add and remove. It might be rather complicated to get a sensible ordering of size-preserving and size-altering mutations, though.
