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 > > > > >
