> Do extra ordering
>guarantees apply only for writes inside constructors or whether they
>extend to all writes that occur prior to publishing?
For initialization safety, the guarantee would be that all writes
performed by the thread between the time the constructor was started
until the time the constructor completes normally are made visible to
all processors before any reference to that object, written after
completion of the constructor, becomes visible.
This is more tightly worded to allow various compiler transformations
on the program, and to allow elimination or combining of the
generated memory barrier if compiler analysis proves you can get away
with it.
But note that we need more than just ordering writes to the fields of
the object being constructed. For example, if in constructing a
string, we allocate an array of characters and then write to the
elements of the array, then anyone seeing the string must see all of
those writes to the string.
By the way, we should also guarantee class initialization safety:
that lack of synchronization doesn't allow you to see the results of
an incompletely executed class initializer. (There are other ways you
can see an incompletely executed class initializer, sort of like the
shooting-yourself-in-the-foot issues for initialization safety).
>If the former, does that mean the "initialize-then-publish" idiom does not
>extend to arrays?
I presume the question references to situations like Foo.x = new int[] {1,2,3};
In this cases, I would argue that we would not support initialization
safety for arrays, primarily because at the bytecode level, there is
no array iniitialization; just allocation of an array of default
values, and then assignment statements. So you couldn't define it at
the VM level. You could define it at the source level, but then would
need to translate it in a way that the VM recognized the special
semantics, and it would only apply to code compiled with new
compilers.
> If the later, what constitutes "publishing", and do the
>extra ordering guarantees apply only to "immutable" objects, or to objects
>whose values stop changing after they are published? If they only apply to
>immutable objects, can arrays be "immutable" (they aren't by Doug's
>definition)?
>
>Raymie
"Publishing" has been imprecisely used to mean making a reference to
an object available to other threads.
I don't think we want to make the guarantees apply only to
"immutable" objects or fields. I think such a scheme would be very
hard to get right. For example, a object that is immutable in
practice may contain a component that is mutable.
I think we shouldn't be promising to forbid all write reorderings.
For example, in the following example
class A {
private Point p;
void setPos(int x, int y) {
p = new Point(x, y);
}
double distanceToOrigin() {
// not synchronized
Point q = p;
return Math.sqrt(q.x*q.x + q.y*q.y);
}
}
the distanceToOrigin function would always give the correct
distanceToOrigin for some position previously applied to setPos, but
the following code for setPos wouldn't work:
void setPos(int x, int y) {
Point tmp = new Point();
tmp.x = x; tmp.y = y;
p = tmp;
}
However, there should be a way to make it work, in case we don't have
an appropriate constructor. Perhaps:
void setPos(int x, int y) {
Point tmp;
synchronized (tmp = new Point()) {
tmp.x = x; tmp.y = y;
}
p = tmp;
}
Bill
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:15 EDT