...
> there is no guarantee that the update to flag will *ever* be seen by the
> first thread. A perfectly reasonable compiler optimization will hoist
> the read of flag out of the loop in the first thread, under the
> assumption that flag will never be changed.
>
> You can't get around this by putting the read of flag in a function,
> either, because functions can be inlined and then optimized.
>
> The point is, again, that you have to be *really* careful about such
> things, and use provided structures like Thread.interrupt() and
> wait()/notify() when you can.
On the side, I believe interruption is best for cancellation only, not
for any other communication--where wait/notify is best used instead.
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
I think more needs to be said about Java programs in terms of what
optimizations can be done in the face of multithreading (and
serialization and reflection). #3 above opens a whole can of worms. I
brainstorm sometimes about an "object oriented optimizer" that crunches
on java bytecodes doing things like removing fields, inlining _classes_,
combining classes that implement different interfaces to the same class,
etc. Multithreading, serialization, and reflection is what makes this
all very harry. On one hand I want to optimize the hell out of those
bytecodes, but on the other hand I don't want unexpected
multithreaded/serialization behavior. Its a contradiction given the
current state of Java.
-- David Smiley
-------------------------------
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