David Smiley said:
> >
> >Anyways...
> > If I think of this from the point of view of an optimizer, I wouldn't
> >removing the "while (!flag)" part because I must always consider the
> >possibility of the presence of some other thread. If I could prove that
> >flag could NOT be set by some other thread since (among other possible
> >reasons):
> > {assume flag is NOT declared public}
> >(1) there is no code that sets it
> >(2) the code that sets it must acquire a lock that is already held by
> >code surrounding the while loop
> >(3) the code that sets it is "not reachable" by a public method or there
> >is no possible chain of method calls from a Runnable in this package
> >that could set it
>
Then Bill said:
> If you don't allow this, you make any optimization of program very
> difficult.
I think that this is a point that may need to be made in an even stronger
fashion. If Java required that reorderings be proven to work before
performing them, the code would run even slower than the way in which it
was written in the first place.
First of all, it would be *extremely* difficult to perform any compiler
optimizations. This is for various reasons: you (David) metioned some of
them.
Second of all, most individual architectures also perform what amounts to
reordering, and the code would have to get around this. For example, on
some SMP architectures, if a thread on processor A is reading a memory
location stored in A's cache, and a thread on processor B writes to the
same memory location, there is no guarantee that the value in A's cache
will be updated. On those architectures, additional instructions would be
needed to make sure that whenever processor A reads that value, it is
getting the value most recently written to memory. This basically makes a
processor cache into a performance bottleneck.
In short, trying to make sure that you are always reading the most
recently written value of a variable is a horrible bottomless pit of
performance into which Java programs would pour many of their clock
cycles.
The proposed changes to volatile variables are a concession to the
programmer in this case: if you think another thread might change the
value, use a volatile. Having one or two volatile variables in a program
isn't going to cause nearly as much trouble as having every variable have
to worry about this stuff.
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:27 EDT