GeeCON Prague 2014*
The moose likes Java in General and the fly likes Will there be any senario where Hashtable and Vector need special code for thread safety Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Java in General
Bookmark "Will there be any senario where Hashtable and Vector need special code for thread safety" Watch "Will there be any senario where Hashtable and Vector need special code for thread safety" New topic
Author

Will there be any senario where Hashtable and Vector need special code for thread safety

Harish Tiruvile
Ranch Hand

Joined: Dec 01, 2005
Posts: 99
Hi,

While going through java tutorials i read we can use Hashtable and Vector collection object's if we need thread safety.

I need to know whether there will be any senario where we need to have extra code for handling thread issues even though we are using able collections ?

Thanks
Harish


Giving up is the easiest thing in the world to do..but holding it together when everything seems like falling apart is true strength!!
with regards, Harish.T
Istvan Kovacs
Ranch Hand

Joined: May 06, 2010
Posts: 100
Both Hashtable and Vector are legacy, synchronized collections. This means that basic operations (adding/putting a value) and reading the collection will not interfere...
... unless you use iterators.
The 'problem' is that synchronized collections (such as Vector, Hashtable and those returned by Collections.synchronizedXyz methods) provide fail-fast iterators. Each collection maintains a modification count; when the iterator is created, it saves the value of the counter, and whenever you call next() on the iterator, it compares the saved value with the current one, and throws ConcurrentModificationException if they differ. The reason is that it's not safe to continue and use the iterator - maybe an element has been added to the collection, which would probably not affect your iteration, but maybe some/all elements were removed, or elements have been inserted at the head of the list.
add(), put() and remove() are all atomic operations. Iterating is not. To iterate safely, you should, before creating the iterator, grab the same lock that the collection's methods use, and not release it until you are done. Note that Vector's Javadoc does not mention whether its methods synchronize on the Vector object itself (which would allow you to synchronize on the Vector), or some internal object (which would make safe iteration impossible).
Be sure to check out for hidden iterators, such as those used by the 'foreach' loop.

To use fail-safe iterators, use CopyOnWriteArrayList or ConcurrentHashMap (or other collection classes in java.util.concurrent).

Aside from iterators, any operation that involves several accesses to the collection (even if it's position based, not iterator-based) would run the same risks. Imagine summing the elements in a list: if you don't do this in a synchronized block (or use CopyOnWriteArrayList), you'll run into consistency issues at all levels (the data, as well as the length of the list may change while you're working on it).

Java Concurrency in Practice is a great book on the topic.
Ireneusz Kordal
Ranch Hand

Joined: Jun 21, 2008
Posts: 423
Read this article:
http://www.ibm.com/developerworks/java/library/j-jtp07233.html
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Will there be any senario where Hashtable and Vector need special code for thread safety