# PR#60: the concurrency category asks for missing synchronization, not for concurrent code

> **WARNING:** This document describes only the change applied in this PR.
> It may already be outdated once the next PR is merged.
> Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.

## The Problem

The category `concurrency` of `jvm-spring-backend` asked whether a change affects concurrent requests,
repeated execution or shared mutable state.
That holds for every change of concurrent code, also a correct one.
On the 30 last merged PRs of werkator, a build system whose core runs builds in parallel,
it would have asked a human for 7 PRs, e.g. for a refactoring of the BuildExecutor;
today, without the template, only the security question asks for 2 of them.
It also rated a correct ConcurrentHashMap with an atomic merge at 0.97, and missed a payment booked again on a retry (0.85).

## Non-Goals

- No change of the other categories.
- No category in `.werkrevisor.toml` yet; the template stays the same for all repositories of its ecosystem.

## The Solution

- The new question asks two things.
  First: do several threads or requests change the same state, without a visible lock or synchronization?
  Second: is an operation no longer safe when it runs twice, e.g. after a retry?
- From 0.9 on, the category gives YELLOW; from 0.99 on, ORANGE.
- docs/werkrevisor.werkbaum: the measurement, and the plan to select the template for werkator and werkprobe.
- werkrevisor 0.28.0.

## Measurement

On 2026-10-08 Jev answered the old and the new question for each main-code file of 30 merged werkator PRs
and 25 merged hs.hsadmin.ng PRs between #281 and #316, and for five constructed diffs.

| case | old question | new question |
|---|---|---|
| defect: a HashMap in a Spring service, changed by concurrent requests | 0.97 | 0.96 |
| defect: a payment is booked again on a retry | 0.85 | 0.90 |
| defect: a Kotlin counter of running builds without a lock | 0.96 | 0.95 |
| correct: a ConcurrentHashMap with an atomic merge | 0.97 | 0.55 |
| correct: a changed log text in the BuildExecutor | 0.22 | 0.07 |
| 55 merged PRs, highest value | 0.98 | 0.70 |

From 0.9 on, the new question finds the three constructed defects and none of the 55 merged PRs.
The defects are constructed and plain, so a real one may score lower.

## Prerequisite PRs

- PR#59: a diagram of the decisions, merged.