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

[davidradl]

see comments