>
> > > Will some thread B calling getLength() ever see [unexpected] results?
> >
> > It's possible.
>
> Oooo, that's just nasty! Are all of you "okay" with this proposed
> behavior? ISTM (it seems to me) that to get any use out of volatile, you'd
> have to declare nearly every member of a potentially shared class as
> volatile. blech!
I seem to have lost an intermediate email, but Joe Bowbeer seems to be
talking about the *current* meaning of volatile. The proposed models
allow volatile to be used for additional memory semantics for
non-volatile fields. So volatile won't be useless.
Specifically, in our model, a read of a volatile field v allows the
reading thread to "see" all of the writes (to volatiles and normal
variables) that were seen by the thread that wrote to v up until the
point at which the thread wrote to it. For further info, check out the
paper,
http://www.cs.umd.edu/~pugh/java/memoryModel/semantics.pdf
A revised version of which will shortly be available; this one is way
out of date.
As a side note, and Bill mentioned this recently, the current memory
model is irrelevant, because a) it is well-nigh incomprehensible and b)
no one follows whatever parts of it they understand anyway. This is why
this list exists. Specifically, volatile isn't even implemented in some
JVMs, even though the architecture requires it. So the use of volatile
now isn't going to buy you anything.
Jeremy
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:31 EDT