Question: SourceFunction

["Matthias J. Sax" <mj...@informatik.hu-berlin.de>]

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

Re: Question: SourceFunction

[Gábor Gévay <gg...@gmail.com>]

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 <al...@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 <
>> mjsax@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
>> >
>> >
>>

Re: Question: SourceFunction

[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 <al...@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 <
> mjsax@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
> >
> >
>

Re: Question: SourceFunction

[Aljoscha Krettek <al...@apache.org>]

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