BUG: Fix ParallelSparseFieldLevelSet deadlock with explicit std::threads

[hjmjohnson]

Fix for the ParallelSparseFieldLevelSetImageFilter dispatch-starvation deadlock demonstrated by #6320. Tracks #6320; depends on it merging first (or rebase against main after #6320 lands so this PR's diff becomes just the .hxx change).

Iterate() dispatches its ThreadedApplyUpdate body via mt->ParallelizeArray(). That body invokes SignalNeighborsAndWait() repeatedly, blocking on per-thread std::condition_variables — the neighbor-only sync protocol therefore requires every work unit to hold its own concurrent OS thread for the full duration of the dispatch. Pool/TBB-backed ParallelizeArray cannot guarantee this: N tasks are queued onto an M-worker pool where M may be < N, and CV-blocked tasks pin all workers so queued tasks never start. Deadlock.

This PR replaces only the one ParallelizeArray call that contains inner SignalNeighborsAndWait with explicit std::thread spawning: work unit 0 runs on the calling thread, N − 1 std::threads are spawned for the remainder and joined at the end. The existing neighbor-only signal/wait protocol (SignalNeighborsAndWait/SignalNeighbor/WaitForNeighbor and the m_Semaphore/m_Lock/m_Condition data members) is left untouched — the bug was that the dispatcher couldn't satisfy the protocol's requirement, not the protocol itself.

Scope

The other ParallelizeArray invocations in Iterate() (ThreadedCalculateChange, ThreadedLoadBalance1, ThreadedLoadBalance2, the post-process pass) stay on ParallelizeArray. They do not call SignalNeighborsAndWait inside the body, so no CV-blocking happens inside the dispatch and pool/TBB scheduling works for them.

SignalNeighborsAndWait and all the supporting machinery are unchanged.

Verification

Local soak on a 16-core x86 box with TBB enabled:

Test	master (no fix)	with this PR
Baseline itkParallelSparseFieldLevelSetImageFilterTest (image-compare), TBB ×100	94/100	100/100
Robustness test from #6320, TBB ×30	0/30 (100% deadlock)	20/20
Robustness test, POOL ×20	20/20 (no worker shortage path)	20/20
Robustness test, PLATFORM ×20	20/20 (no worker shortage path)	20/20

The baseline image-compare against Baseline/BasicFilters/ParallelSparseFieldLevelSetImageFilterTest.mha passes bit-identically.

Why explicit std::thread rather than a global barrier

A first attempt replaced the neighbor-only signal/wait with a generation-counted global barrier (std::mutex + std::condition_variable + arrival counter). The global barrier itself was correct, but it required all N waiters to be simultaneously live — which ParallelizeArray still cannot guarantee under TBB worker shortage. The global-barrier rewrite had a worse deadlock rate (27% per run) than the original.

Explicit std::thread spawning sidesteps the dispatcher's worker-count limit entirely: each work unit gets its own OS thread, lives for the full dispatch, and the unchanged neighbor sync protocol completes naturally.

[hjmjohnson]

The deadlock this PR is fixing traces directly to Dženan's 2018–2019 refactor: replacing the global memory barrier with neighbor-only SignalNeighborsAndWait condition variables dispatched via ParallelizeArray is exactly the design that can't be satisfied under TBB worker-shortage (N CV-blocked tasks pin M<N workers). The original Awate algorithm and the protocol itself are sound; the dispatcher assumption introduced during the barrier-removal modernization is what breaks.

[dzenanz]

The fix looks good. I don't have enough time to review the test.

[blowekamp]

My initial instinct that is a "WaitForThreads" blocker in a ParallelizeArray call is a violation of independence of the element computation. I presume that such an algorithm could easily be converted into two passes over the array.

@dzenanz I think the documentation for this method in MultiThreaderBase should be updated to clarify the requirements of the calling function.

[dzenanz]

documentation for this method in MultiThreaderBase should be updated

You could propose a PR with the clarifications you would like to be there 😄

[blowekamp]

I spent some time further looking at the algorithm. I am not convinced that other deadlocks do not exist with other multi-threaders with different number of threads and work units due to the blocking for neighbors.

I believe the easiest change to make to preserve this original algorithm which assumes a fixed number of threads and work units is to hard code usage of the PlatforMultiThreader. Similar to what is done here:

ITK/Modules/Segmentation/SuperPixel/include/itkSLICImageFilter.hxx

Line 49 in 7d01b0e

this->SetMultiThreader(PlatformMultiThreader::New());

Ideally another algorithm would be implemented which does not use blocking and waiting.

[hjmjohnson]

Superceeded by: #6337