Assigning handle classes in a parfor loop

I have been doing some calculations which are output by assigning data to a handle class array. The calculations run fine when I use a for loop but when I try to parallelise this by conversion to a parfor loop, the assigned data are no longer there when the parfor loop ends.

The documentation alludes to this as follows: "Changes made to handle classes on the workers during loop iterations are not automatically propagated to the client."

This implies that it may be possible for such changes to be propagated back, even if it's not done automatically. Does anyone know how I might do this?

Here is some example code:

classdef Example < handle

    properties
        data
    end

    methods
        function obj = Example(data)
            obj.data = data;
        end

        function setData(obj,data)
            obj.data = data;
        end

        function data = getData(obj)
            data = obj.data;
        end
    end
end

Now here is some example code which generates an array of these objects and then assigns values to them in a parfor loop. Finally we look at the values of the data.

% Function to demonstrate use of Example in a parfor loop

function testExample num = 5;

    % Initialise array of objects
    for n = 1:num
        exArray(n) = Example(zeros(1,6));
    end

    % Set data within a parfor loop
    parfor n = 1:num
        setData(exArray(n),n:n+5);
    end

    % Now look at assigned data
    for n = 1:num
        disp(getData(exArray(n)));
    end

end

When I run this code without the matlabpool open, it behaves as expected:

1 2 3 4 5 6

2 3 4 5 6 7

3 4 5 6 7 8

4 5 6 7 8 9

5 6 7 8 9 10

But when I run with matlabpool open, the updated values are lost outside of the parfor loop, giving this result:

0 0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0 0

Does anyone have any idea how to get around this problem, other than by not using parfor?

[Daniel Shub]

Some additional information about your object and what you are setting would be helpful. Is it a scalar object? How are you currently setting the property?

[Andrew]

Daniel, Thanks for your comment. I have updated the question above. Sorry for not posting it below but it wouldn't format the code...

[tsan toso]

Hi Andrew,

Out of curiosity, could you also use the parfor loop when you first initialize the example class? to make things faster?

-tsantoso

Answer 1

[Andrew]

I have received an answer to this issue from technical support. Apparently the Mathworks regard it as a 'feature' that changes to objects are not returned - though I can't see that it's a very useful feature. Anyway, the way to get modified class properties returned from a parfor loop is to make an explicit change which can be recognised by parfor. Here are two examples which work for the above example object:

    parfor n = 1:num
        exArray(n).data = n:n+5;
    end

or

    parfor n = 1:num
        temp = exArray(n);
        setData(temp,n:n+5);
        exArray(n) = temp;
    end

Actually, if you change any object property it also seems to work. So for example this also works, if there is a second property data2 which is set explicitly, both data and data2 are correctly returned:

      parfor n = 1:num
          setData(exArray(n),n:n+5);
          exArray(n).data2 = n:n+5;
      end

[Edric Ellis]

I would say that rather than a "feature", it's an almost inevitable limitation given that the PARFOR loop iterations are executing inside different MATLAB worker processes, potentially on physically separate machines. If changes to a handle object could somehow be reflected back to the client automatically, then concurrent accesses to the handle would need to be managed - this would fundamentally go against PARFOR's "independent iterations" design.

[Arnon]

Thank you, very helpful discussion. I have a parfor with trees of objects being edited on the workers. I pass a root to each of the workers. I can make one visible change to a root property in each, following the spirit of this answer. Is there any information of how deep the copy would go, when invoked?

(It could be easy to just try it, however I first need to remove some global variables from the code as the parfor does not transfer these to the workers either).