Gil>I'd be happy
I wish you all the best. I truly adore the way you explain things.
Gil>There is no contract I've found that establishes a
happens-before relationship between the initialization of non-final fields
in some object construction and the put of that object (or of some object
that refers to it) as a value into the CHM.
In this case that contract is provided by JLS "17.4.3. Programs and Program
Order" and "17.4.5. Happens-before Order" .
TL;DR: "If x and y are actions of the same thread and x comes before y in
program order, then hb(x, y)."
Let me take an example:
class Wrapper {
int value;
}
static CHM map;
Thread1:
val w = new Wrapper();
w.value=42;
map.put("wrap", w);
Thread2:
val u = map.get("wrap");
if (u != null) { println(u.value); }
1) In thread 1 there's happens-before between write "value=42", and write
of "w" into the map since "program order implies happens-before"
2) CHM provides happends-before for non-null retrieval of the value
3) "retrieval of the value u" happens-before "read of u.value" since
"program order implies happens-before"
The happens-before order is a partial order, so it is transitive, so 1+2+3
gives "write of value=42 happens-before read of u.value".
The key point of having a CHM is to have 2 (happens-before across threads)
which is not provided automatically if simple HashMap is used.
What do you think?
Gil>It is true that* in current implementation* a put() involves a volatile
store
JavaDoc contract is there, so CHM would provide "happens-before relation
between update and non-null retrieval" in future one way or another.
Vladimir
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
