[
https://issues.apache.org/jira/browse/ZOOKEEPER-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated ZOOKEEPER-5052:
--------------------------------------
Labels: pull-request-available (was: )
> Fix stale thread write of primitive in JvmPauseMonitor
> ------------------------------------------------------
>
> Key: ZOOKEEPER-5052
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-5052
> Project: ZooKeeper
> Issue Type: Bug
> Reporter: Dávid Paksy
> Assignee: Dávid Paksy
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a classic concurrency problem in JvmPauseMonitor: a non-volatile
> shared primitive variable is being updated by one thread, making the new
> value invisible to other threads.
> Problematic fields:
> {noformat}
> private long numGcWarnThresholdExceeded = 0;
> private long numGcInfoThresholdExceeded = 0;
> private long totalGcExtraSleepTime = 0;
> {noformat}
> We discovered this because JvmPauseMonitorTest has timed out intermittently.
> The Problem
> In the Java Memory Model, threads use local memory caches for performance.
> When a thread updates a primitive (like int, boolean, or double) without
> proper synchronization, the change stays in that thread's local cache. Other
> threads reading that variable will continue seeing the old, "stale" value,
> resulting in race conditions or infinite loops.
> The Fix
> Add volatile to the three long counters: this ensures all threads read the
> latest value directly from main memory.
> Using AtomicLong would be an overkill here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
