Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Assigning handle classes in a parfor loop

Asked by Andrew on 20 Jan 2012
Latest activity Commented on by tsan toso on 22 Oct 2013

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?

3 Comments

Daniel on 20 Jan 2012

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 on 20 Jan 2012

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 on 22 Oct 2013

Hi Andrew,

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

-tsantoso

Andrew

1 Answer

Answer by Andrew on 26 Jan 2012
Accepted answer

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

2 Comments

Edric Ellis on 26 Jan 2012

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 on 30 Nov 2012

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).

Andrew

Contact us