Running with assertions and a non-zero knowledge threshold in lock-free mode will cause some assertions to fail. In particular, the way we handle terminal states (by deleting all children) can cause SgUctChildIterator to discover it has no children (in SgUctSearch::UpdateRaveValues and SgUctSearch::SelectChild) which it asserts is not true. It is also possible for threads to play into filled-in cells during the in-tree phase.
It is possible our opponent has winning VCs that are not derived from the winning SCs in our list. Thus, we may want to consider overlapping the winning VCs as well.
The "vc-pattern-file" option is not checked here. This means that creating a VCPatternSet for board size (x,y), changing "vc-pattern-file", and then asking for a pattern set for (x,y) will not cause a re-build. No one will want to do this anyway (right?), so it doesn't matter. If you really want to do this, add the filename as part of the key for VCPatternSetMap.