Exceptions for using global variables in parfor loops

Hi,

I've read on Matlab central that Matlab does not allow the use of global variables in a parfor loop. Though, there are still some cases for which "global" variables would be of high interest at the individual worker level/parfor iteration.

Example: I'd like to execute a code for several independent entities (one entity per parfor iteration), and this code is rather complex, relying on nested functions and a large set of parameters that I store in global variables for the sake of easiness (much easier than passing all parameters as function inputs).

More specifically, I accept the fact that global variables defined at the worker level/for a given iteration could not be used afterwards at the client level or at another worker level/another iteration (it would be meaningless in the case of parallel computing), but I'm very embarassed by the fact that global variables can't be defined at the worker level within each given iteration, for a use only at that specific worker level/iteration. In other words, I'm talking here about "global variables" only valid at the worker level, which means that the 'global' terminology does not hold in the classic sense, but still holds regarding the way such variables can be used (e.g. defining and then calling them in separate functions).

Is it possible to force Matlab to allow this use? If not, is there already a patch allowing it or can it be foresee in a next release (hopefully soon)?

Thanks and cheers,

[Stephen23]

Put the parameters in one structure and pass that as an input.

[tom3w]

Thanks, this option will indeed definitively work. I'm still examining if it's still possible to use global variables for this purpose; if this is not the case, I'll probably implement this.

Answer 1

[Walter Roberson]

Is it possible to force Matlab to allow this use?

NO

If not, is there already a patch allowing it or can it be foresee in a next release (hopefully soon)?

NO. This is unlikely to be supported any year soon.

The work-around is not difficult: put the reference to the global variables inside of functions that are called within the parfor body. As you indicated, you would still have to manage the fact that the global variables apply per-worker.

[tom3w]

Thanks for the answer. This is what I had in mind; but when doing so, aren't the values of the global variables (e.g. defined before the parfor loop and called in a function within the parfor loop) expected to be reset to empty by the loop?

[Walter Roberson]

Yes, correct, each worker will have the globals initialized to empty, no matter what value the variable might have had in the client.

You can use parfevalOnAll() to run code on each of the workers to initialize them. That might be most easily done by passing in a struct and setting the global variables according to the structure member names. Not generally recommended coding style, of course, but then using global is not recommended coding style either...

[tom3w]

Thank you Walter for the suggestions. I'll probably use input structures to replace global variables initialized before the parfor loop and, as a complement, initialize "global" variables at the worker level for a local use at that level.