Thread-safety bug in RobustPredicates workspace arrays under concurrent triangulation

[uuiitwp1]

RobustPredicates holds instance-level workspace arrays used by InCircleAdapt for adaptive exact arithmetic. RobustPredicates.Default is a singleton, shared by all Mesh instances. When multiple threads concurrently call GenericMesher.Triangulate() → Dwyer.Triangulate() → InCircle → InCircleAdapt, they mutate the same workspace arrays, producing corrupted intermediate values. This manifests non-deterministically as NullReferenceException in TriangleLocator.Locate or "Unable to find a triangle on path" in ConstraintMesher.FindDirection.

[wo80]

Thanks for reporting! A quick fix would be to create a lock at

Triangle.NET/src/Triangle/RobustPredicates.cs

Lines 235 to 236 in 613ad53

	return InCircleAdapt(pa, pb, pc, pd, permanent);
	}

Could you test this and maybe do a pull request?

[uuiitwp1]

The lock around InCircleAdapt works — I tested it under 1000 concurrent triangulations and it eliminates the race. I can submit a PR with that fix.

However, the root cause is that RobustPredicates.Default is a singleton, and every concurrent triangulation shares the same instance-level workspace arrays (fin1[1152], fin2[1152], temp64[64], etc.) mutated by InCircleAdapt. A one-line alternative avoids serialization entirely:

public static RobustPredicates Default => new();

Each Mesh gets its own workspace, zero lock contention. Same observable behavior — the static constructor still initializes epsilon/splitter once. Which approach would you prefer for the PR?

[wo80]

Well, that would defeat the purpose of having the singleton. Could you test setting the Predicates factory of the Configuration class. By default it uses the singleton, but you could set it to always return a new instance, or, if you have full control of your worker threads, try the following example code:

Triangle.NET/src/Triangle.Examples/Examples/ExamplePar.cs

Lines 39 to 53 in 613ad53

	for (int i = 0; i < concurrencyLevel; i++)
	{
	tasks[i] = Task.Run(() =>
	{
	// Each task has it's own triangle pool and predicates instance.
	var pool = new TrianglePool();
	var predicates = new RobustPredicates();
	// The factory methods return the above instances.
	var config = new Configuration()
	{
	Predicates = () => predicates,
	TrianglePool = () => pool.Restart(),
	RandomSource = () => Random.Shared
	};

[wo80]

Have you tried the above approach? If that works, I would refrain from adding the lock and instead add some remarks about thread-safety to the readme and wiki.

[uuiitwp1]

Your per-thread factory approach does work, and I confirmed it eliminates the race. The issue is that my codebase calls through ExtensionMethods.Triangulate():

public static IMesh Triangulate(this IPolygon polygon, ConstraintOptions options, QualityOptions quality, ...)
{
    return new GenericMesher().Triangulate(polygon, options, quality, cancellationToken);
}

GenericMesher's parameterless constructor internally does new Configuration(), which hardcodes () => RobustPredicates.Default. I can't inject a per-thread predicates factory without either forking the extension method or changing the default Configuration behavior globally — both of which touch code I'd rather keep upstream-compatible.

Thanks for the quick response and suggestions.

[uuiitwp1]

Have you considered using stackalloc for the workspace arrays in FastExpansionSumZeroElim, InCircleAdapt, etc.? Happy to submit a PR if you're interested.

https://github.com/uuiitwp1/Triangle.NET/blob/master/src/Triangle/RobustPredicates.cs#L716

[wo80]

Delayed response, because I took the weekend off...

Have you considered using stackalloc for the workspace arrays

Valid solution, but comes with the cost of introducing the unsafe keyword, which I usually try to avoid, if not absolutely necessary. Could use Span, but that means we get a dependency on System.Memory and its dependencies...

I can't inject a per-thread predicates factory without either forking the extension method or changing the default Configuration behavior globally

May I ask how you implement the parallel execution? IMHO the ExamplePar code mentioned above isn't too complex and should be easily incorporated into your existing code (even when using Parallel.For or Parallel.ForEach).