Transparency violation error (?)

[Yannick]

Hi,

could anyone point out to me why the following example only works until I uncomment the commented line?

>> clc;
>> clear all;
>> parfor i = 1 : 1
>> A = 1;
>> eval('1');
>> %eval('A');
>> end

The output is:

> ans =
>
> 1
>
> ??? Error using ==> parallel_function at 594
> Error in ==> parallel_function>make_general_channel/channel_general at 886
> Transparency violation error.
> See Parallel Computing Toolbox documentation about Transparency.
>
> Error in ==> Untitled at 3
> parfor i = 1 : 1

I just don't see the "transparency violation" as A is local.

Best,
Yannick

[Jos Martin]

Yannick,

The definition of transparency is

The body of a parfor-loop must be transparent, meaning that all references to variables must be "visible" (i.e., they occur in the text of the program).

When you uncomment the line and add

eval('A');

you introduce a reference to the variable A (via the eval command) that is not visible and hence not transparent.

To see that this isn't transparent, consider if we wrote the following

variableName = 'A';
A = 0;

parfor i = 1:1

eval( variableName );
end

This is virtually identical to your code, yet you can see that inside the parfor loop MATLAB cannot know what is going to be eval'd and hence transparency is violated.

Hope that helps

Regards

Jos

"Yannick " <bers.rem...@gmx.net> wrote in message <h766cv$74s$1...@fred.mathworks.com>...

[Yannick]

Hi Jos,

thank you for your reply. The difference between your code and mine is, however, that A is a local variable in my example, and an outside-of-the-parfor variable in yours.

The first example in the explanation of transparency from [1] reads:

In the following example, because X is not visible as an input variable in the parfor body (only the string 'X' is passed to eval), it does not get transferred to the workers. As a result, MATLAB issues an error at run time:
>>X = 5;
>>parfor ii = 1:4
>> eval('X');
>> end

Now, moving the definition and initialization of X from outside the loop to inside of it, X IS definitely on every worker. So, the main problem that causes transparency violations should not be present any more, but I still get this error.

Is this intended?

Best,
Yannick

[1] http://www.mathworks.com/access/helpdesk/help/toolbox/distcomp/index.html?/access/helpdesk/help/toolbox/distcomp/bq__cs7-1.html

[Jos Martin]

Hi Yannick,

Apologies for failing to point out that the transparency requirement applies to all variable types (including temporary variables, or as you refer to them local variables).

Thus the following code is expected (and BTW required) to error

variableName = 'A';

parfor i = 1:1
A = 1;

eval( variableName );
end

So the behaviour you are seeing is expected.

If you want to get around this behaviour then write a subfunction (or other function) that you call from the parfor. A function called from inside a parfor no longer has the transparency requirement. For example

- begin m-file -
function someFuntion
parfor i = 1:10
% This workspace is transparent
iCanDoEval
end

function iCanDoEval
% This workspace is NOT transparent
A = 1;
eval('A');
- end m-file -

Regards

Jos

"Yannick " <bers.rem...@gmx.net> wrote in message <h76jkn$32h$1...@fred.mathworks.com>...

[Yannick]

Hi Jos,

thanks for all the explanations and examples. This also implies (does not explain, though, but that's OK) why a non-function .m file inclusion completely fails with parfor - even with only temporary variables:

parfor i = 1 : 5
A = 1;
LoopBody;
end

LoopBody.m:
disp(A);

This is another problem I was facing, but now I do understand that this is expected to fail. Perhaps this is a point to update in the manual, because the "has not been transferred to all workers" explanation does not cover this (or the previous) case failing.

Using a non-function m file is by the way my way of allowing the body loop to use "continue", which would not be as straightforwardly possible in a function without additional control return parameters.

Best,
Yannick

"Jos Martin" <jos.mart...@mathworks.com> wrote in message <h7886k$rck$1...@fred.mathworks.com>...

[Yugeng He]

That is not what the OP asked. He defined A inside the parfor loop. It doesn't violate the transparency principle.

"Jos Martin" <jos.mart...@mathworks.com> wrote in message <h769eg$4ru$1...@fred.mathworks.com>...