[hotfix] make previousCpuTicks and previousProcCpuTicks volatile to increase visibility for all threads

[bjornarjatten]

What is the purpose of the change

This pull request fixes a visibility issue in the SystemResourcesCounter class by marking previousCpuTicks and previousProcCpuTicks as volatile.

Previously, these variables were not declared as volatile, meaning updates made by one thread might not be immediately visible to others. This could lead to stale values being read by different threads.

By making these variables volatile, we ensure that all threads see the most up-to-date values, preventing inconsistencies.

Brief change log

• Marked previousCpuTicks and previousProcCpuTicks as volatile to ensure proper visibility across threads.

Verifying this change

This change is a trivial rework/code cleanup without any test coverage.

Does this pull request potentially affect one of the following parts?

• Dependencies (does it add or upgrade a dependency)? No
• The public API (i.e., is any changed class annotated with @Public(Evolving))? No
• The serializers? Unsure
• The runtime per-record code paths (performance sensitive)? Unsure
• Anything that affects deployment or recovery (JobManager, Checkpointing, Kubernetes/Yarn, ZooKeeper)? Unsure
• The S3 file system connector? Unsure

Documentation

• Does this pull request introduce a new feature? No
• If yes, how is the feature documented? Not applicable

[flinkbot]

CI report:

• 529badb Azure: FAILURE

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[davidradl]

I had a look at the usages of these 2 fields
it seems previousCpuTicks is only updated if it is null. Which looks very strange - is this right? I can see that volatile could be useful here if this is correct processing.

previousProcCpuTicks is updated when null then after processing in the method see code here. I wonder if the
previousCpuTicks logic should update it, in the same way as previousProcCpuTicks .

I was looking at these usages to see if AtomicReference should be used rather than volatile. This would be more thread safe, and to use compareAndSet() to update it.

[bjornarjatten]

It seems to me that it is also the only place it can be initialized.

I agree with AtomicRefrence, I was thinking about the same thing. Should I add an commit with that? :)

[davidradl]

see comments

[github-actions]

This PR is being marked as stale since it has not had any activity in the last 90 days.
If you would like to keep this PR alive, please leave a comment asking for a review.
If the PR has merge conflicts, update it with the latest from the base branch.

If you are having difficulty finding a reviewer, please reach out to the
community, contact details can be found here: https://flink.apache.org/what-is-flink/community/

If this PR is no longer valid or desired, please feel free to close it.
If no activity occurs in the next 30 days, it will be automatically closed.