[
https://issues.apache.org/jira/browse/ZOOKEEPER-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dávid Paksy reassigned ZOOKEEPER-5052:
--------------------------------------
Assignee: Dávid Paksy
> 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
>
> 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
> Since we so compound operations (incrementing) on these, we shall use Java's
> java.util.concurrent.atomic classes.
> {noformat}
> private final AtomicLong count = new AtomicLong(0);
> // To update: count.incrementAndGet();
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
