> From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com]
>
>
> At 03:28 PM 4/1/2003, Boehm, Hans wrote:
> >Just to clarify:
> >
> >I'm proposing two changes:
> >
> >1) Synchronization ==> reachable
> >
> >2) Referenced by reachable through volatile or final ==> reachable
>
> This is a minor tweak. I would add array references too.
>
> volatile X[] aX = ...;
>
> There is no way to make the array elements themselves
> volatile, so without
> special casing arrays you couldn't use them to keep things reachable.
>
I initially liked this idea, but after thinking about it more, I'm not so sure. It does have the advantage that it would probably not have a major impact on the compiler.
Its main problem is that if X is reachable, X[3] refers to object a, and then a thread executes the assignment
X[3] = null;
there are few constraints on when that assignment becomes visible to other threads. Hence the notion of an array element referring to an object at a particular program point is not at all well-defined, unlike for volatile or final fields where it at least makes some sense. As a result, I think this property would be quite hard to use, unless the array element is effectively constant.
In general, it seems to me that the absence of volatile array elements is basically a defect in the language. I see no good reason (except perhaps syntactic inconvenience) for it, and it prevents me from writing some useful programs. I suspect it's also the major obstacle to a "make everything sequentially consistent by declaring everything volatile" javac option, which would probably be very useful for debugging.
It's probably beyond our charter to try to do anything about this issue. But if we wanted to address the problem, I think it would be far better to address it directly than to add kludges elsewhere to make it more palatable.
Hans
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:43 EDT