Matrix operations answer wrongly when called from more than one thread

[Rafael-SOWNet]

Fixes #1219.

MathS.Multithreading documents concurrent use as supported, and matrix operations do not honour it.

The cause is not in this repository. GenericTensor 1.0.4 keeps two process-wide mutable statics. I have reported it as GenericTensor#40 with a fix in GenericTensor#41. This PR is what stands in until a release carrying that fix exists, and GenTensorGuard says in its own doc comment that it should be deleted when one does.

Measured

Forty 4×4 matrices with non-polynomial entries, on c2c8eb83, each computed once sequentially and then rebuilt and recomputed under Parallel.For:

	disagreements
Determinant	38 of 40
Inverse	18 of 40
Adjugate	11 of 40
m + m, m - m, PointwiseMultiplication	throws, on a corrupted Dictionary

Nothing about the first three looks wrong. They are well-formed entities of the right shape carrying another computation's values.

Two statics, opposite treatments

Only one of them can be closed without a lock, which is why this is not a single uniform guard.

The scratch-matrix pool behind DeterminantLaplace and Adjoint hands every caller the same tensor for a given size, and the caller writes into it. There is nothing to warm and no way to sidestep it from out here, so those three call sites take a lock. It serialises determinants and inverses of matrices that PolynomialDeterminant.Of declines — the polynomial elimination runs first and never reaches the pool, which is why the entries in the test are sines and cosines, and why a polynomial matrix was never affected.

The compiled-operation cache behind the elementwise operators is an unsynchronised Dictionary, so it is unsafe only while it is being filled; once an entry is there the reads are pure. That one takes no lock, because the set of entries this library can ever ask for is fixed and tiny: Entity.Matrix rejects any tensor that is not rank 2, and every call site here uses the default single-threaded mode, so the only reachable keys are addition, subtraction and multiplication at rank 2. Filling all three once under Lazy leaves the dictionary read-only from then on, at no steady-state cost.

Answers are unchanged

No BREAKING-CHANGES.md entry: a single-threaded caller computed these values before and computes the same ones now. The change is that a concurrent caller now does too.

On the tests

Both halves have a trap in them and I walked into each one first.

The determinant tests rebuild their matrices inside every pass. Determinant, Inverse and Adjugate are cached lazy properties, so reusing the instances lets the parallel pass read what the sequential pass already computed — the test is green because the operation ran once.

The elementwise test has no sequential pass at all, for the mirror-image reason: computing the expected values first populates every cache key before the threads start, and the test then passes against the unguarded code.

All four fail on c2c8eb83 and pass here. Full suite green: 8499 and 1485.

🤖 Generated with Claude Code

https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura