MATLAB Answers

Critical code section inside parfor

4 views (last 30 days)
With C++ one can define critical code section inside a parallel for.
Is there a similar construct that can be used with Matlab?
e.g. suppose that a shared variabe has to be infrequently updated, but must be shared.
With C/C++ we might use a typical construct such as this:
#pragma omp for
for (...) {
// Do something with elements indexed by loop control variable
// and use some shared resource in calculations
if (update_required) {
#pragma omp critical
// Critical block can only be entered by 1 thread at a time
{
// update shared resource
}
}
}
For instance, insert a new key-value pair into a shared hashtable inside the loop; a rare event, but nevertheless the update must be safely shared by all executing threads.

Accepted Answer

Walter Roberson
Walter Roberson on 17 Feb 2021
parfor does not share variables with other threads.
Unless you are calling an external function such as https://www.mathworks.com/matlabcentral/fileexchange/28572-sharedmatrix or you are updating a memory mapped file https://www.mathworks.com/help/matlab/ref/memmapfile.html then the only way you can update a variable in another worker is to use a parfor data queue to send the value to the client, and have the client send the value to the other workers.
"global" variables are not shared. graphic objects are not shared.
  2 Comments

Sign in to comment.

More Answers (1)

Edric Ellis
Edric Ellis on 18 Feb 2021
Further to Walter's response, the closest analogy in parfor is a reduction variable. These may appear to be updated by multiple loop iterations concurrently, but the parfor machinery (and language constraints) ensure that the result is computed deterministically with no race conditions. I.e. the following is supported, and completely deterministic.
list = [];
parfor i = 1:100
list = [list, i];
end
  7 Comments
Edric Ellis
Edric Ellis on 22 Feb 2021
I would not recommend that pattern, as it can lead to deadlock. labSend does not necessarily complete until the corresponding labReceive has started. Therefore, you can easily end up with all workers stuck trying to call labSend simultaneously (e.g. if they all wish to send on the first iteration). In practice, small messages get sent immediately by labSend using underlying buffering, but it is definitely not a good idea to rely on that. The "safe" version of that pattern unfortunately loses efficiency because it requires a synchronisation point after each "compute the next thing". Something like
spmd
while ~done
compute the next thing
% all-to-all communication to disseminate values
if the computation required a new hash key
toCommunicate = {newkey, newvalue};
else
toCommunicate = {};
end
allNewKeysAndValues = gcat(toCommunicate);
updateCache(allNewKeysAndValues);
done = % some other collective decision
end
end

Sign in to comment.

Products


Release

R2020b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by