Files
meshcore-analyzer/cmd/server
efitenandClaude Opus 5 5e45796148 test(server): set the #1239 lock-hold threshold from measurement, 150µs to 5ms
Replaces the per-run calibration from the previous commit, which was built
on a wrong assumption. That commit assumed the writer's Lock/Unlock cycles
were slowed by the CPU load of eight busy readers, and calibrated against a
control where the readers churned a second store the writer never locks.

CI measured that control at 0µs: under a microsecond per cycle. The readers'
CPU load costs the writer nothing, so the variance comes from lock handoff,
which only exists when the readers touch the same mutex. The control could
not see the thing it was supposed to subtract.

The same runs produced the numbers that settle it:

  healthy    156µs, 222µs, 402µs   (three commits; 402µs from run 35252186369)
  regressed  201203µs              (fork run 35252430017, RLock deliberately
                                    held across the compute)

The separation is a factor of 500, not a factor of 2, so nothing clever is
needed: the flat limit only had to stop sitting inside the healthy band.
5ms is 12x above the worst healthy reading and 40x below the measured
regression.

This also refutes the argument in #2038 against simply raising the limit,
which claimed 400µs would no longer separate healthy from mildly regressed.
A #1239 regression serializes a millisecond-scale compute behind every
writer, so it cannot be mild.

Refs #2038, #1239

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013YAR8fdNTzqjtsggq4xCX6
2026-09-17 19:30:37 +02:00
..