Andreas Leitgeb wrote:
Patricia Shanahan <pats@acm.org> wrote:
Andreas Leitgeb wrote:
Thread 1 assigns two plain word-sized fields: a and then b.
can Thread 2 happen to see b's new value, and (after that) a's old
value?
Depends on the memory order rules in the hardware. I'm most familiar
with the rules for SPARC v9, but other processors have their own rules.
In Total Store Order they cannot reverse. In Relaxed Memory Order and
Partial Store Order, they can reverse, from the point of view of other
processors, unless some action such as a membar #StoreStore forces
ordering.
See
http://en.wikipedia.org/wiki/Memory_ordering#In_SMP_microprocessor_systems
Thanks for the processor-specific infos.
It means, that an attempt to "produce" such a reversion (in the sense as
one can "produce" a deadlock) may be doomed if on the "wrong" platform.
Keep in mind that it's not just hardware implementation that affects this.
Compiler optimizations can change the order of reads and writes as well.
The bottom line is that if the order of reads and writes is important,
there needs to be some kind of synchronization in the code to accomplish
that. It may be sufficient to specify "volatile", or a more costly
synchronization technique may be needed (such as acquiring the monitor for
an object).
This is true even if running the code on a single-core CPU.
Presumably, the choice of the existing hashCode() implementation for
String was made based on the assumption that the overhead of even
"volatile" was more important to avoid than the remote possibility that
multiple threads may wind up calculating the hash code for the same string
instance.
And, also presumably, this is the same thinking that led to the code in
which those unfortunate strings with a hash code of 0 always wind up
getting recalculated no matter what (because otherwise, one would need a
flag, separate from the hash code field, which could wind up out-of-sync
with the hash code field absent synchronization, such as "volatile"?as
discussed previously in this thread).
Or simply giving them an arbitrary different value for hashCode() (e.g. 1),
which is vanishingly unlikely to create any problems. (Though it does break
the explicit contract of String.hashCode(), which would need to be changed.)