Processes vs Threads Pool for parfor with Large Shared Read-Only Data

Initial Pool Choice Criteria

The Parallel Computing Toolbox recommends the Processes pool for general parfor use. Switch to Threads only when the per‑worker memory footprint would otherwise exceed the available RAM because each worker would need to duplicate the large read‑only array. In practice:

• Determine the size of the constant matrix (≈10 GB).
• Estimate the base MATLAB memory per worker (≈1–2 GB on a typical machine).
• If base + 10 GB would exceed the RAM allocated to one worker, prefer Threads to avoid duplication.
• If the workers can comfortably hold the matrix plus overhead, default to Processes for isolation.

For the described workload, the 10 GB matrix will almost certainly push a single worker beyond its memory budget, so Threads is the first choice – provided the external library is thread‑safe.

Verifying Thread‑Safety of an External Library

When source code cannot be changed, a pragmatic verification is to run the library under both single‑threaded and multi‑threaded conditions and compare results. A minimal test script looks like:

%% Baseline (single‑threaded)
ref = zeros(1,1000);
for i = 1:1000
    ref(i) = external_mex_call(i);  % replace with your call
end

%% Parallel test (Threads pool)
parpool('threads',4);  % or the size you plan to use
parfor i = 1:1000
    out(i) = external_mex_call(i);
end

disp(all(out == ref));  % should return true if thread‑safe

Any discrepancy indicates unsafe behavior. For a more thorough check, run the test with different thread counts (2, 4, 8) and vary the input pattern. If results remain deterministic, the library is likely safe for the workload. If you have access to dynamic analysis tools (Intel Inspector, Valgrind Helgrind, ThreadSanitizer), attach them to the MATLAB process during the parfor run to catch data races or lock‑related issues.

Inspecting Worker Memory Layout

MATLAB exposes worker memory usage via the memory function inside a worker. To confirm whether the 10 GB matrix is shared or duplicated:

parpool('processes',2);
parfor i = 1:2
    memBefore = memory('all');
    A = largeReadOnlyMatrix;  % your 10 GB matrix
    memAfter = memory('all');
    fprintf('Worker %d: increase = %g MB\n', i, memAfter.MemUsageAllArrays - memBefore.MemUsageAllArrays);
end

Repeat with a Threads pool. In a Threads pool the increase should be near zero (the matrix is shared). In a Processes pool it will be roughly the matrix size per worker.

Practical Recommendations

• Start with a Threads pool if memory is a concern, but run the thread‑safety test first.
• If the library fails the test, fall back to Processes even at the cost of duplication.
• Document the chosen pool and the test results so that future iterations can reuse the decision.
• When switching pools, remember that MATLAB clears the current pool and any persistent workspace variables; plan the change at a session boundary or save necessary data to disk.

Do you know the MATLAB version you are using? The memory function and the exact pool naming conventions are stable from R2022a onward, but minor differences may exist in earlier releases.