Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Atomic vars in multithreaded env. ++num and num++ operations aren… #16356

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -56,6 +56,7 @@
import java.util.Comparator;
import java.util.List;
import java.util.concurrent.Executor;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicReference;
import java.util.function.Consumer;

Expand Down Expand Up @@ -155,7 +156,7 @@ public SearchPhaseController.ReducedQueryPhase reduce() throws Exception {
aggsList,
topDocsList,
topDocsStats,
pendingMerges.numReducePhases,
pendingMerges.numReducePhases.get(),
false,
aggReduceContextBuilder,
performFinalReduce
Expand Down Expand Up @@ -239,7 +240,7 @@ private MergeResult partialReduce(
}

public int getNumReducePhases() {
return pendingMerges.numReducePhases;
return pendingMerges.numReducePhases.get();
}

/**
Expand All @@ -264,7 +265,7 @@ private class PendingMerges implements Releasable {
private final SearchPhaseController.TopDocsStats topDocsStats;
private volatile MergeResult mergeResult;
private volatile boolean hasPartialReduce;
private volatile int numReducePhases;
private final AtomicInteger numReducePhases = new AtomicInteger();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need to change this to AtomicInteger?

If usage of an int hasn't been resulted in any issue so far as we know, then I think we might just add unnecessary overhead of using AtomicInteger over an int.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a definite issue here. But no one digs that deeply and reports it, if faces.
++num and num++ operations aren't atomic, so you can get an out-of-sync value from time to time

Copy link
Contributor

@sandeshkr419 sandeshkr419 Nov 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think your analysis is entirely accurate.

The increment operation (++numReducePhases) is performed within a thread-safe block. Specifically, tryExecuteNext() method begins by acquiring a synchronized lock on this.

We’d benefit from AtomicInteger instead of volatile int if numReducePhases were incremented outside of a synchronized block or lock-free code which is not the case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sandeshkr419 You are right. That was the only previously approved change and it's uneecessary. I'm going to close this PR


PendingMerges(int batchReduceSize, int trackTotalHitsUpTo) {
this.batchReduceSize = batchReduceSize;
Expand Down Expand Up @@ -448,8 +449,7 @@ protected void doRun() {
long estimatedMergeSize = estimateRamBytesUsedForReduce(estimatedTotalSize);
addEstimateAndMaybeBreak(estimatedMergeSize);
estimatedTotalSize += estimatedMergeSize;
++numReducePhases;
newMerge = partialReduce(toConsume, task.emptyResults, topDocsStats, thisMergeResult, numReducePhases);
newMerge = partialReduce(toConsume, task.emptyResults, topDocsStats, thisMergeResult, numReducePhases.incrementAndGet());
} catch (Exception t) {
onMergeFailure(t);
return;
Expand Down
Loading