False Negative: DoubleCheckedLockingWithInitRace.ql misses initialization races once the double-checked pattern is split across helpers or early returns.

# False Negative: DoubleCheckedLockingWithInitRace.ql misses initialization races once the double-checked pattern is split across helpers or early returns.

Version
codeql 2.24.3

## Checker
- Checker id: `Likely Bugs/Concurrency/DoubleCheckedLockingWithInitRace.ql`
- Checker description: This checker detects a potential race condition in double-checked locking patterns where a field assignment inside a synchronized block may be visible to other threads before subsequent side-effect statements are executed.

## Description of the false negative
These samples still publish `f` before the rest of the initialization work is complete. One variant moves the synchronized initialization into a helper, and the other rewrites the fast path as an early return, but the initialization race is the same.

## Affected test cases
### `PosCase1_Var3.java`
The helper call only hides the same double-checked-locking race where publication happens before later side effects.

```java
// Double-checked locking with assignment to another field after the field assignment should be flagged as potential race condition.
package scensct.var.pos;

public class PosCase1_Var3 {
private Object f;
private Object otherField;

public Object getF() {
if (f == null) {
initField();
}
return f;
}

private void initField() {
synchronized (this) {
if (f == null) {
f = new Object();
otherField = new Object();
}
}
}
}
```

### `PosCase1_Var5.java`
This still publishes the initialized object before a later field assignment completes, which is the race the query is meant to catch.

```java
// Double-checked locking with assignment to another field after the field assignment should be flagged as potential race condition.
package scensct.var.pos;

public class PosCase1_Var5 {
private Object f;
private Object otherField;

public Object getF() {
if (f != null) {
return f;
}
synchronized (this) {
if (f == null) {
f = new Object();
otherField = new Object();
}
return f;
}
}
}
```

## Cause analysis
The query appears too tied to one inline statement ordering pattern for double-checked initialization. Once the synchronized block is extracted into a helper or the fast path is expressed as an early return, it stops recognizing that `f` becomes visible before the remaining side effects complete.

That is a real concurrency gap. Initialization races often survive exactly this kind of refactoring.

## References
None known.

Start by reading Likely Bugs/Concurrency/DoubleCheckedLockingWithInitRace.ql and the PosCase1_Var3.java and PosCase1_Var5.java examples. Trace how the query handles helper calls and early returns, then verify that both initialization-race variants are flagged.

Written by the indexing model from the issue text.