"valid indices for 'a' are restricted in PARFOR loops" for unindexed struct?

73 views (last 30 days)
For the following code:
parfor k = 1:2
a.b = k;
end
I'm getting the error "valid indices for 'a' are restricted in PARFOR loops"
But there is no indexing here. Could someone explain what I'm missing?
In case it's important, the code above comprises the entire script.
Edit: I found the documentation which explicitly states that you can't do what I'm trying to do:
You cannot create a structure in a parfor-loop using dot notation assignment.
It's not clear why, though.
Edit 2: Mathworks support has submitted an enhancement request to update the error message to something clearer in a future release.
MATLAB Version: 9.1.0.441655 (R2016b)

Answers (1)

OCDER
OCDER on 16 Jul 2018
Edited: OCDER on 16 Jul 2018
parfor k = 1:2
a(k).b = k;
end
The reason a.b = k does NOT work is because when the parfor finishes, and there are, say N workers creating 1000 parallel versions of a.b = k, which one is going to be the final a.b? If 1000's of parallel universes converge into 1 universe, which universe will we be the "real" universe? Error error.
But, a(k).b = k works because each worker creates its own separate variable (or isolated universe), a(1).b, a(2).b, ..., a(N).b. No conflict issues.
In the example, this works too because temp is defined inside the parfor, which tell matlab "this is a temporary variable that's created in the parallel world - do not bring it to the real world"
parfor i = 1:4
temp = struct(); %What's created in the parallel world stays in the parallel world
temp.myfield1 = rand();
temp.myfield2 = i;
end
  7 Comments
Evan
Evan on 17 Jul 2018
Edited: Evan on 17 Jul 2018
@OCDER I appreciate your perseverance. I stepped away from this for a day to give it a fresh look. I think I have thought of a logical reason why a.b=k doesn't work. If the struct a is defined before the parfor loop, it would seem strange for a.b=k to completely wipe the previous a object, whereas a=struct() does this explicitly. And it is not possible to know by looking at the code whether a will be in the workspace before the code is run (e.g. a load operation).
Or maybe someone from Mathworks will jump in and give the true reasoning. But in any case, I think I would have figured this out more quickly if the error message was more precise about what I was doing wrong. Hopefully the enhancement request goes through.

Sign in to comment.

Categories

Find more on Parallel for-Loops (parfor) in Help Center and File Exchange

Tags

Products


Release

R2016b

Community Treasure Hunt

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

Start Hunting!