Interference in parfor when using global variables

I have a function, which includes many nested functions, for estimation of a model. Inside the function, a global variable is created and it changes across iterations of the algorithm. If I were to run the function in parallel using parfor, is there a risk of interference between the loops? I suppose that since the global variable is created inside the main function, it should be "worker-specific", hence inaccessible for other workers.

Notes: Yes, I'm not a fan of global variables either but the code is quite involved. I needed to make a few adjustments and using a global variable was by far the easiest option.

[Rik]

As far as I'm aware, the state of a global variable is transmitted to the worker when the loop is entered.

But if your global variable is changing between itterations, isn't it an intended effect that itterations affect each other?

A general word of caution: temporary fixes have a habit of staying around, especially if they are low-quality and hard to implement properly. Just have a look at the US constitution: a document fixed with a string of ammendments, instead of a properly rewritten text.

Answer 1

[Edric Ellis]

Separate workers have their own completely separate global workspaces. If the function that you call from parfor first assigns a value to a global variable, and then it is used by other functions called from that first function, then things will work as expected. However, it is extremely difficult to have confidence that this is what's going to happen. This is just one of the reasons why global variables are not recommended.

For instance, consider the following code:

parfor i = 1:10
    out(i) = mySafeTopFcn(i);
    out2(i) = myDodgyTopFcn(i);
end

%% Safe functions
function out = mySafeTopFcn(in)
global STATE
STATE = in; % Always completely assigns STATE
out = mySafeInnerFcn(in);
end
function out = mySafeInnerFcn(in)
global STATE
out = in + STATE;
end

%% Dodgy functions
function out = myDodgyTopFcn(in)
global DODGY_STATE
if isempty(DODGY_STATE)
    DODGY_STATE = 0;
else
    % Unsafe - uses prior value of DODGY_STATE
    DODGY_STATE = 1 + DODGY_STATE;
end
out = myDodgyInnerFcn(in);
end
function out = myDodgyInnerFcn(in)
global DODGY_STATE
out = in + DODGY_STATE;
end

It's hard to tell without looking at all the code that the "safe" versions will return reproducible results because of the way the global state is set up, whereas the "dodgy" versions will return results that depend on the number of workers in the pool, and how the work is divided up.