On 10/5/07, MenTaLguY <[EMAIL PROTECTED]> wrote: > > 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. >
I've questioned whether this was actually safe (hence the call-out in the code), but at least one thread I read in the JMM mailing list archives seemed to suggest that a compiler would not reorder the write to table[index] WRT the write to e.value, which is the issue. It did seem to me that this was not much different than setting the field in the constructor. In any case, the readValueUnderLock technique isn't too terribly painful; we don't actually (intentionally*) store any null values right now (though that could change in a lightweight implementation in which null represented Ruby nil), and, as noted in a comment in ConcurrentHashMap, no compiler is currently (at the time the comment was written, anyway) known to reorder object initialization WRT an array store of that object, so the readValueUnderLock method is unlikely ever to be called. The added overhead, therefore, is just a DUP, ASTORE, IFNULL, ALOAD sequence for each read. (Still, a nanosecond here, a nanosecond there, before you know it you're talking real time...) Anyway, I'm glad you brought this up, I was hoping someone would either confirm or contradict the assumptions of this approach. -Bill
