The body of a parfor
-loop or spmd
block
must be transparent, meaning that all references
to variables must be "visible" (i.e., occur in the text
of the program).
In the following examples, because X
is not
visible as an input variable in the loop or block 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 | X = 5; spmd eval('X'); end |
Similarly, you cannot clear variables from a worker's
workspace by executing clear
inside
a parfor
or spmd
statement:
parfor ii = 1:4 <statements...> clear('X') % cannot clear: transparency violation <statements...> end | spmd; clear('X'); end |
As a workaround, you can free up most of the memory used by a variable by setting its value to empty, when it is no longer needed:
parfor ii = 1:4 <statements...> X = []; <statements...> end
Or in the case of spmd
blocks, you can clear
its Composite from the client workspace.
In general, the requirement for transparency restricts all dynamic access to variables, because the entire variable might not be present in any given worker. Therefore, variable creation, deletion, modification, access, and querying that is not explicitly specified by the program is prohibited in a transparent workspace.
Examples of some other actions or functions that violate transparency are:
evalc
, evalin
, and assignin
with
the workspace
argument specified as 'caller'
save
and load
, unless the output of load
is
assigned to a variable.
Running a script from within a parfor
-loop
can cause a transparency violation if the script attempts to access
(read or write) variables of the parent workspace. To avoid this issue,
convert the script to a function and call it with the necessary variables
as input or output arguments.
MATLAB does successfully execute eval
and evalc
statements
that appear in functions called from the parfor
body.