A parfor is run synchoneously. That is, the parfor is blocking until complete. By that logic, two parfor loops can only run sequentially, as such
parfor idx = 1:N
...
end
% Can't be reached until 1st parfor loop is complete
parfor jdx = 1:M
...
end
What gets posted occasionally is nested parfor loops.
parfor idx = 1:N
parfor jdx = 1:M
...
end
end
The flaw here is that workers do not communicate with each other in parfor loops. Therefore, worker 1 (in the idx parfor) can't send iterations (from the jidx parfor) to worker W.
To answer your question, you would create one parfor with N workers to run all your code.
With that said, there is another option to consider. If these 4 for-loops could run at the same time, refactor the code into their own subfunction and then look at using parfeval or batch. For instance, let's assume your code looks something like this overly simplified example
% 4 independent loops that can run at the same time
for idx = 1:N1
A(idx) = . . .
end
for idx = 1:N2
B(idx) = . . .
end
for idx = 1:N3
C(idx) = . . .
end
for idx = 1:N4
D(idx) = . . .
end
Refactor it as follows:
A = for_fcn1(n1);
B = for_fcn2(n2);
C = for_fcn3(n3);
D = for_fcn4(n4);
The refactored code could be of the form
function ret = for_fcn1(n)
for idx = 1:n
ret(idx) = . . .
end
Now use parfeval
fcns_to_call = {@for_fcn1, @for_fcn2, @for_fcn3, @for_fcn4};
num_fcn_outputs = {n1, n2, n3, n4};
cluster = parcluster;
pool = cluster.parpool(4);
for idx = 1:4
f(idx) = cluster.parfeval(fcns_to_call,num_fcn_outputs(idx), . . .);
end
for idx = 1:4
% Block until "future task" is complete
[. . .] = f.fetchNext;
end
% Continue with your serial code.
The code with ". . ." will require more input on your part. Look at the doc for parfeval and it should be more obvious what they are.
