Concurrency on tsvinc

The race detector saw my requests in order

Thu, 29 Oct 2026 00:00:00 +0000

I run a small Go proxy on my LAN, in front of the GPU boxes that serve my local LLMs. Clients can ask it for a model by a short alias, and it looks the alias up in a map to decide where the request goes. That map can now be replaced while the proxy is running, by a config reload, so every read of it has to take a lock. A read that skips the lock is the kind of bug that does nothing at all until one request lands in the middle of a reload, and I have no interest in meeting it there.

The lock map deleted a mutex someone was waiting on

Tue, 27 Oct 2026 00:00:00 +0000

Assumes you have guarded per-key work in Go with a map of mutexes. Builds on 29 of 34 passing agent runs had a blocker the hidden tests never saw.

This series is about the A9, my 128 GB AMD Strix Halo test box (a GEEKOM A9 Mega: Ryzen AI Max+ 395, 128 GB of soldered LPDDR5X-8000), and lately about one question: can a model running on it, locally, do a developer's job as a coding agent? The study that asks it is a grid: several models, the same ticket-style tasks for each, more than one agent harness, and I grade what each run leaves behind. The grading has several layers, on the theory that any one of them can be fooled and fooling all of them at once is harder. This post is about a run that fooled every layer but one, and I wrote one of the fooled layers myself.

The shutdown grace that never ran

Sun, 25 Oct 2026 00:00:00 +0000

The net/http documentation spends two sentences on the trap, in the comment on Server.Shutdown:

// When Shutdown is called, [Serve], [ServeTLS], [ListenAndServe], and
// [ListenAndServeTLS] immediately return [ErrServerClosed]. Make sure the
// program doesn't exit and waits instead for Shutdown to return.

My LAN proxy for local models did the other thing. It started Shutdown in a goroutine with a five-second budget, let ListenAndServe return, and returned from main. Until v0.3.0, every restart cut every stream going through it within milliseconds of the SIGTERM, logged nothing about the requests it cut, and exited with status 0. The proxy needs a restart after every config edit, and its streams are coding agents' turns against models on two GPU boxes, which can run for minutes.

The fixes had the bugs

Sat, 24 Oct 2026 00:00:00 +0000

Marking a fix done sounds like the easy part. Write the change, write a test, watch the suite go green, tick the box. I had 45 findings for my LAN proxy for local models, from a round of research into what coding agents and other clients send and what llama.cpp's endpoints expect. I had an afternoon of fixes, and a green suite.

The fixes then went through an independent re-review, pass after pass, each one starting from the findings and the code rather than from my summary of what I'd done. Seven passes found 11, 8, 10, 4, 2, 1 and 0 bugs. They weren't new findings about clients. They were in the fixes, and in the fixes of the fixes, and two of them could take the whole proxy down.

The deadlock test can't see a half-held lock

Tue, 13 Oct 2026 00:00:00 +0000

Assumes you have written a two-account transfer under per-account locks, and know what a mutation test is.

At 128k context and a four-hour budget, four 27B local models ran a Zig ledger task 36 times through OpenCode. All 36 passed all 15 hidden core tests. All 36 had written their own concurrency test with real threads, because the prompt asked for one.

Then the scorer removed the second account lock from each transfer and ran everything again. The hidden suite failed on every mutant it could score. The models' own suites failed in 4 of 11 scoreable spec runs, 0 of 9 clean review runs, and 6 of 9 test-first runs.

Zig's defer ends at the closing brace

Mon, 12 Oct 2026 00:00:00 +0000

Assumes you have guarded a critical section with a mutex and defer unlock in Go.

Moving money between two accounts under per-account locks has one famous trap, and it is the order. Lock A then B in one thread, B then A in another, and the two transfers deadlock. The textbook answer is to sort the IDs and always lock the lower one first. It is in every concurrency chapter.