>
>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
You are supposed to use synchronization or volatile to indicate that
another thread might modify a variable. Without either of those, the
compiler is free and encouraged to assume that it is the only thread
touching the variable.
If you don't allow this, you make any optimization of program very
difficult. Further, I have become convinced that even if such a model
were guaranteed, 99% of programmers who tried to make use of those
guarantees would be badly burned.
Use synchronization and/or volatile (once we get volatile fixed). It
isn't that expensive, and it serves as important and useful
documentation to programmers about the intended thread interactions
in your code.
Bill
-------------------------------
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