On Fri, 2007-10-05 at 16:58 -0700, Bill Dortch wrote: > - In general, synchronized (or synchronized-access) HashMaps are > replaced with custom concurrent hash implementations.
There is a data race here: // external volatile value initialization intended to obviate the need for // readValueUnderLock technique used in ConcurrentHashMap. may be a little // slower, but better to pay a price on first write rather than all reads. e = new VariableTableEntry(hash, name.intern(), table[index]); e.value = value; table[index] = e; variableTableSize = potentialNewSize; variableTable = table; // write-volatile Since table[index] is not a volatile location, other threads are allowed to see the write to table[index] before the write to e.value; it is possible to get "phantom nulls". The fact that e.value is a volatile location means only that reads of e.value will see all writes up to and including a write to it; it doesn't enforce the non-visibility of subsequent writes. Whether the write to e.value happens in or out of the constructor doesn't really matter. If you want to avoid the need for readers to test for phantom nulls, one valid approach would be to make "value" a final field; updates could then be accomplished by rebuilding the appropriate prefix of the bucket-list with new VariableTableEntries. -mental
signature.asc
Description: This is a digitally signed message part
