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 happen: http://stackoverflow.com/questions/25425130/loop-doesnt-see-changed-value-without-a-print-statement Gabor 2015-06-22 17:13 GMT+02:00 Stephan Ewen <se...@apache.org>: > 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 > here. > > On Tue, Jun 16, 2015 at 4:08 PM, Aljoscha Krettek <aljos...@apache.org> > wrote: > >> 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 < >> mj...@informatik.hu-berlin.de> >> wrote: >> >> > 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 implemented as a private/protected member variable), and thus, >> > declaring it volatile should not be necessary. >> > >> > Do I miss anything? >> > >> > -Matthias >> > >> > >>
