Paul's suggestion would work under my proposed semantics for volatile
variables (that a read is treated as an acquire and a write is
treated as a release).
class VolatileArray {
private volatile int macguffin;
private int[] data;
public VolatileArray(int cap) {
data = new int[cap];
macguffin = 0;
}
public int get(int i) {
int tmp = macguffin;
return d[i];
}
public void set(int i, int value) {
d[i] = value;
macguffin = 0;
}
}
The fact that I put a write to macguffin into the constructor would
also mean that we wouldn't have to depend on initialization safety of
non-final variables (we could, instead, make data final, but perhaps
we don't want it to be final).
Note that the value of macguffin is never used, but that the compiler
must not eliminate semantics of usunused reads of volatile variables
(under my new proposed semantics). However, in this case a compiler
might be able to eliminate the actual reads and writes to macguffin,
just leaving in the appropriate memory barriers.
If a compiler could prove that a particular VolatileArray was only
accessed by a single thread, it would be legal to eliminate the
memory barriers associated with that instance.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:23 EDT