OctoGo v0.2.2 A livelock in the channel rendezvous is fixed. Programs with a few channels and a few goroutines could hang on hardware at a rendezvous, with both sides live and neither progressing: the polling loops asked for the hub lock every turn, which re-takes it faster than the cog on the other side can win it. Anyone writing concurrent code on v0.2.1 or earlier is affected, so this is worth taking. Each poll now reads the volatile flag it is waiting on before asking for the lock, and asks only when there is plausibly something to do. The check inside the lock is still the authoritative one. Builds no longer pass --fcache=0. The flag had been there since the hang was first seen, on the belief that flexspin's FCACHE was miscompiling the rendezvous. It was not: FCACHE only made the loop fast enough to expose the livelock, and disabling it turned off loop caching for every program to hide a bug in three loops. Both halves of that are now undone, so compiled programs get loop caching back. What settles the diagnosis is that varying only the backoff moves the hang -- one cycle stops after two exchanges of four, eight after three, sixty-four completes -- which a stale read could not do. Thanks are owed to Wuerfel_21 on the Parallax forum for saying it was a bug in the logic exposed by faster timings. doc/rendezvous-livelock.c, which used to claim this was a compiler bug, now demonstrates the fix and reproduces the hang under -DLIVELOCK. Verified on a P2-EDGE: all 37 test programs built with the real backend, loaded onto the board and checked against their serial output, with FCACHE on. A new case covers sustained traffic -- three pipelines, seven cogs polling at once -- and hangs outright without the fix.