I'm not sure I understand the consequences of:
> V4
> // Does volatile guarantee fresh values for direct contents of referenced
> // object even if referenced through a different name?
> Initially:
> volatile Node p;
> volatile Node q;
>
> Thread 1:
> Node tmp1 = new Node();
> q = tmp1;
> tmp1.x = 1;
> p = tmp1;
>
> Thread 2:
> Node tmp2 = p;
> int tmp3 = q.x;
>
> Question: Is it possible that thread 2 gets a value of 0 in tmp3?
Naively anyway, this seems to require non-data-flow-driven compilers
encountering methods with ref args, such as say,
void setContents(Node node, int v) { node.x = v; }
to pessimistically treat node as if it could be volatile, since
setContents(tmp1, 1) could be called instead of the direct
assignment here. Or am I missing an obvious way to avoid this?
In any case, this one clashes with my intuitions about volatile.
I don't expect volatileness to "transfer" across assignments
among reference variables or when binding arguments.
I similarly don't understand rationale behind:
> V5
> // Does volatile guarantee fresh values for direct contents of
> referenced object
> // through multiple levels of indirection?
> Initially:
> volatile Node p;
>
> Thread 1:
> Node tmp1 = new Node();
> Node tmp2 = new Node();
> tmp1.next = tmp2;
> tmp2.x = 1;
> p = tmp1;
>
> Thread 2:
> int tmp3 = p.next.x;
>
> Question: Is it possible that thread 2 gets a value of 0 in tmp3?
If people want such effects, don't you think that they should have
to define Node as:
class Node {
int x;
volatile Node next;
}
On the other hand, the equally-excessive V6 is useful since it
provides a workaround for the fact that you cannot declare array
elements as volatile. But maybe there ought to instead be a special
rule for this?
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-341-2688 FAX:315-341-5424 http://gee.cs.oswego.edu/
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:24 EDT