Re: what the benefit is by using annotation, like "@Immutable" ?
Lew wrote:
Yes. Don't omit what tom said about /happens-before/:
In fact, it's worse than that. Thread A could finish the method and update
both calculated and code, but because there is no happens-before relationship
between thread A and thread B, it's possible that B could come along later,
and see the updated calculated but *not* the updated code. So even without
an unlucky timeslice end, there is no guarantee of safety here.
Andreas Leitgeb wrote:
There is still a misunderstanding - I'm just not sure if it's on my or your
side.
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?
Yes.
Tom's explanation was (as far as I understood it) based on the code-sample
where the flag was set before the code, and he rightly pointed out that this
gap may be even much longer than expected. Can it reverse, as well?
Yes.
When thread A changes values for shared data 'a' and 'b' without establishment
of /happens-before/, at some later time (even chronologically after both
values were changed), a different thread B can examine those data and find any
of four states: the old value for both 'a' and 'b', the old value for 'a' and
new for 'b', the new value for 'a' and old for 'b', or the new value for both.
You'll need multiple cores to encounter these scenarios, most likely, and it
will depend on whether they use a NUMA, various caching strategies, how far
apart in the memory architecture the cores are, the load at the time, ...
Andreas Leitgeb wrote:
Has anyone found e.g. an english [sic] dictionary-word with hashCode 0, yet?
Or perhaps the name of some commonly used class in Java standard library
or some other String likely occurring in innocent code?
Lew wrote:
Andreas Leitgeb wrote:
Damn, I shouldn't have trimmed the "non-trivial" that I had already written.
At least, the hashCode for "" is quite efficiently obtained.
It's not really trivial. "" is an extremely common 'String' value and
frequently can be the key to a hashed structure, so its hash value is relevant.
--
Lew