A Free Model Endpoint Said the C++ Lock Was Hot. The Race Detector Disagreed.

#testing #ai #cpp #devops

One afternoon, a developer opened a one-line review comment on a small C++ service. The comment said the mutex was unnecessary. The reasoning was short. Each worker already had a local sum. The final write would happen after all threads joined. The model was calm. The model was wrong.

The case below is a simplified reproduction, not a production incident. The developer ran the review through MonkeyCode's free model access. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The free server option let the review loop run on a temporary host instead of the developer's laptop.

The original service

#include <mutex>
#include <thread>
#include <vector>
#include <iostream>

std::mutex sum_mtx;
int shared_sum = 0;

void worker(int start) {
    int local = 0;
    for (int i = start; i < start + 1000; ++i) {
        local += i;
    }
    std::lock_guard<std::mutex> lk(sum_mtx);
    shared_sum += local;
}

int main() {
    std::vector<std::thread> pool;
    for (int i = 0; i < 8; ++i) {
        pool.emplace_back(worker, i * 1000);
    }
    for (auto& t : pool) {
        t.join();
    }
    std::cout << shared_sum << std::endl;
}

The model's suggestion

The free model produced a diff. It removed the lock and wrote directly to shared_sum.

    int local = 0;
    for (int i = start; i < start + 1000; ++i) {
        local += i;
    }
-    std::lock_guard<std::mutex> lk(sum_mtx);
    shared_sum += local;

The model claimed the join sequence made the final write safe. It did not. The write to shared_sum still happened inside each worker thread. A join only blocks the main thread until each worker finishes. It does not rearrange the writes into one thread.

The developer did not merge. He built a detector.

The harness

The harness compiled both variants with ThreadSanitizer and ran them twenty times. ThreadSanitizer is a race detector. It reports a data race when two threads access the same memory without synchronization and at least one access is a write.

#!/usr/bin/env bash
set -euo pipefail

# original.cpp has the mutex, patched.cpp does not
for file in original patched; do
  c++ -g -O1 -fsanitize=thread -fno-omit-frame-pointer $file.cpp -o $file -pthread
done

for i in $(seq 1 20); do
  ./original >/dev/null 2>original.$i.log || true
  ./patched  >/dev/null 2>patched.$i.log  || true
done

echo original race reports: $(grep -l 'WARNING: ThreadSanitizer' original.*.log | wc -l)
echo patched race reports:  $(grep -l 'WARNING: ThreadSanitizer' patched.*.log | wc -l)

The first run produced no warning. The fifth run produced one. The race did not appear every time. That was the point. A single execution of the patched binary would have been misleading.

One report looked like this:

WARNING: ThreadSanitizer: data race
  Write of size 4 at address ...
  Previous write of size 4 at address ...

The original variant stayed silent across all twenty runs. The patched variant produced a warning in fourteen of them.

The decision table

The developer used a simple rule. A model suggestion could touch locking only if the race detector stayed silent.

| Variant | Lock held | Race reports in 20 runs |
| original | yes | 0 |
| patched | no | 14 |

The table was not about trusting the detector blindly. It was about making the risk visible.

Why the model was useful

The free model still helped. It proposed a cleanup. The developer did not have to guess what a reviewer might say. The harness turned the proposal into a test. The model was not a judge. It was a source of hypotheses.

Limitations

ThreadSanitizer only catches races that execute. If a test input does not exercise the conflicting code path, the race stays hidden. The harness also needs a compiler with sanitizer support. A free server may have limits that are not known here. The developer should not treat one clean run as proof.

Who should not use this

Teams that cannot run sanitizers in their build environment should not copy this pattern. Teams that only use the model as a reviewer should not use this as a substitute for human review. Safety-critical code needs a different bar.

The same harness can sit behind MonkeyCode's free server option if a team wants a shared veto job. Otherwise it runs well on a laptop.

DEV Community