DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=36541>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 ------- Additional Comments From [EMAIL PROTECTED] 2005-09-15 16:57 ------- Syncing reads in addition to writes > (which already prevents data corruption, and is done again in the entire 5.5 > branch) provides very little, since your reads are going to be dirty anyway > unless you sync yourself at the application level. Basically, the > ConcurrentHashMap, which uses the same algorithm as the regular HashMap, just > does an additional synced read if the result was null to the initial unsynced read. I don't want to flog a dead horse, but I do not think the above is correct. Normally "Dirty Read" means that you can read an uncommitted transaction. In this case, it means that you can get an incorrect read when looking at a peice of data that no one else is touching. E.g. If someone is adding Item X, you may be prevented from seeing Item Y. This is mostly caused by the resize issue alluded to above, and is addressed by ConcurrentHashMap much differently than it is addressed in HashMap. If you look at the Get code for ConcurrentHashMap: V get(Object key, int hash) { if (count != 0) { // read-volatile HashEntry<K,V> e = getFirst(hash); while (e != null) { if (e.hash == hash && key.equals(e.key)) { V v = e.value; if (v != null) return v; return readValueUnderLock(e); // recheck } e = e.next; } } return null; } HashEntry<K,V> getFirst(int hash) { HashEntry[] tab = table; return (HashEntry<K,V>) tab[hash & (tab.length - 1)]; } The code in getFirst first sets the table to a local variable, this is probabaly meant to get around the issue brought up by issue#72 where the table can change between gettting the table length and then accessing an index in that table. In addition to this, there are a lot of other differences between ConcurrentHashMap and Hashmap that address a number of these subtle issues. Look at the differences between ConcurrentHashMap$Segment.rehash() and HashMap.transfer(). Hashmap.transfer() simply transfers all the entries over to the new list. ConcurrentHashMap$Segment.rehash() needs to determine which entries can be moved over and which need to be copied so that it can keep the current table used by the ConcurrentHashMap valid. The overall point here is that concurrency issues are subtle, and using data structures that are not meant to be used concurrently in a concurrent manner can be dnagerous. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
