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 23:18 ------- Actually, for completeness, I thought I would mention some of the other more subtle differences between HashMap and ConcurrentHashMap that make this dangerous. In both HashMap and ConcurrentHashMap adding a new entry comes down to a line that looks something like: table[bucketIndex] = new Entry<K,V>(hash, key, value, e); Looks safe, right? Problem is that Entry<K,V>.next is not final, so it need not be actually flushed to memory by the time table[bucketIndex] is set. For ConcurrentHashMap, HashEntry<K,V>.next is declared final, so it must be flushed to memory before the constructor is finished. This means that for the HashMap case, when doing a get, you can get this partially created instance and not look down the rest of the chain, and thus not find your element. In the ConcurrentHashMap case, this cannot happen because of the above mentioned "final" variable. For more info on this read section 17.5 of the JVM spec as it is revised for 1.5 http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.5 -- 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]
