HPCC4J-644 FileUtilityTest atomic record count false sharing

[jpmcmu]

• Fixed false sharing on atomic counter in FileUtility

Signed-off-by: James McMullan [email protected]

Type of change:

• This change is a bug fix (non-breaking change which fixes an issue).
• This change is a new feature (non-breaking change which adds functionality).
• This change is a breaking change (fix or feature that will cause existing behavior to change).

Checklist:

• I have created a corresponding JIRA ticket for this submission
• My code follows the code style of this project.
  • I have applied the Eclipse code-format template provided.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly, or...
  • I have created a JIRA ticket to update the documentation.
  • Any new interfaces or exported functions are appropriately commented.
• I have read the HPCC Systems CONTRIBUTORS document (https://github.com/hpcc-systems/HPCC-Platform/wiki/Guide-for-contributors).
• The change has been fully tested:
  • This change does not cause any existing JUnits to fail.
  • I have include JUnit coverage to test this change
  • I have performed system test and covered possible regressions and side effects.
• I have given due consideration to all of the following potential concerns:
  • Scalability
  • Performance
  • Security
  • Thread-safety
  • Premature optimization
  • This change fixes the problem, not just the symptom

Testing:

[github-actions]

Jira Issue: https://hpccsystems.atlassian.net/browse/HPCC4J-644

Jirabot Action Result:
Workflow Transition To: Merge Pending
Updated PR

[jpmcmu]

@ghalliday @mckellyln Atomic counter fix. Note: FileUtility is a debugging utility, doesn't affect end user code

[rpastrana]

@jpmcmu this looks like a sensible fix based on the offline explanation you provided on the atomic increment issue.

[jpmcmu]

Background information on the issue regarding the atomics:

Atomics are fast as long as the cache line that is storing that atomic is in the CPU core's local cache, but when running with a bunch of threads each CPU core first has to request that cache line be moved to their local core's cache before it can be incremented. The end result is each thread is waiting around for that cache line to be moved their core so they can increment it. The result of this false sharing is a problem a lot like lock contention even though atomics are lockless.

[rpastrana]

Background information on the issue regarding the atomics:

Atomics are fast as long as the cache line that is storing that atomic is in the CPU core's local cache, but when running with a bunch of threads each CPU core first has to request that cache line be moved to their local core's cache before it can be incremented. The end result is each thread is waiting around for that cache line to be moved their core so they can increment it. The result of this false sharing is a problem a lot like lock contention even though atomics are lockless.

Thanks for tracking this down @jpmcmu

[jpmcmu]

@rpastrana retargeted to 9.6.x

[github-actions]

Jirabot Action Result:
Added fix version: 9.6.48
Added fix version: 9.8.22
Workflow Transition: 'Resolve issue'