Hi,
There is one more tricky issue here if the variable is not volatile,
which can cause a problem on any architecture: If the compiler
determines that the code inside the loop will never modify isRunning,
then it might "optimize" the exit condition into just while(true).
And this can actually ha
The run() and cancel() methods are definitely called by different flags.
On most architectures, it would not make much difference whether the field
is volatile or not, because non.volatile field values propagate into other
caches fast as well. Guarantees about "happens before" are also not needed
But the sources stay inside they run() method the whole execution time, per
design. That's why another thread needs to call cancel() on the source to
break it out of this (in most cases) infinite loop.
On Tue, 16 Jun 2015 at 14:13 Matthias J. Sax
wrote:
> Hi,
>
> I just encountered, that the (ne
Hi,
I just encountered, that the (new streaming API) SourceFunction
interface method cancel() states in the JavaDoc, that one might have a
"volatile field 'isRunning'". Why should this member be volatile? I do
not see why different thread should access this field (I would claim, it
will be impleme
