Doug emailed me to say that he was a little confused about what Foo.a
and Foo.p were. They were intended to be static fields of the class
Foo, and Foo.a was an object used for locking.
If it makes things clearer, here is a Java source version of the example:
class Foo {
static Point p;
static synchronized void t0() {
Point tmp = new Point();
tmp.x = 1;
p = tmp;
}
static synchronized void t1() {
Point tmp = p;
System.out.println("T1: " + tmp.x);
tmp.x = 2;
}
static void t2() {
Point tmp = p;
tmp.x = 3;
}
static synchronized t3() {
Point tmp = p;
System.out.println("T3: " + tmp.x);
}
Assume that t0, t1, t2, and t3 are all invoked by separate threads,
and that synchronization on the Foo class object forces t0, t1 and t3
to be executed in serialized in that order.
Without thread 2
* t1 prints "T1: 1"
* t3 prints "T3: 2"
When we add in t2, we have the following constraints:
* When t1 prints tmp.x, it must not print 0, the initial value of tmp.x
(i.e., it can print 1 or 3).
* When t3 prints tmp.x, it must not print either 0 or 1
(i.e., it can print 2 or 3).
And just to completely repeat myself, the requirement is:
* Among a set of threads that are properly synchronized, certain writes
will not be visible to certain reads (of the same variable)
because they have
been overwritten.
Adding additional (perhaps incorrectly synchronized) reads or writes to the
program must not make visible any of the writes previously considered to be
overwritten.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:28 EDT