Dávid Paksy created ZOOKEEPER-5052:
--------------------------------------
Summary: 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
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)
