Read/Write Limitations with Parallel Computing Toolbox (parfor)

I am working on implementing Parallel Computing Toolbox (specifically parfor) to a pre-existing program, but I am noticing some potential concerns and cannot find many resources online regarding it. Do any of these functions risk read collisions? fileparts, isempty, eval (when calling a MATLAB file directly)

Additionally, with diary, if you start diary before the parfor loop, will all workers log? And if you start a log in the worker (with a custom name between all workers), would each worker log individually?

Answer 1

[Edric Ellis]

• Generally speaking, parfor is conservative in what it allows to ensure that by default, all variable accesses are safe.
• It is safe to call fileparts inside parfor, but it is not necessarily safe to perform file access from multiple workers concurrently.
• As Walter points out, eval is forbidden in the body of a parfor loop to ensure it does not perform any operations that compromise the analysis of the loop (i.e. by accessing the workspace of the loop body); you are free to call functions that use eval internally, this is safe.
• If you start diary at the client, it will capture everything printed at the client's command-window (i.e. including output from all workers)
• If you start diary on a worker (ensuring that it gets a unique filename to avoid collisions...), then it will capture output from only that worker.

[Maxwell]

Thanks both for the responses, it's been a great help. Is there any source that this information is covered in that I couldn't find online?

Answer 2

[Walter Roberson]

parfor does not use shared memory, at least not classically. It uses java queuing operations to transfer data between workers, with it being unspecified (at least at the MATLAB level) exactly how Java does its transporting.

The model is that each worker gets a read-only copy of any variable that is not detected as being an output-only or input-output object. The only supported output is by indexing by the loop control index, or sometimes by appending (see reduction variables.) The loop control index operations are examined at parse time to ensure that the indexed segments cannot overlap.

fileparts and isempty would be operating on sliced or distributed variables, or on local variables, with updates from other workers not possible. (And if you use a dataqueue to send values between client and worker then you are getting an unshared copy of the data.)

eval() is not permitted directly in parfor. eval() is permitted within a function invoked from within a parfor loop -- and since it is inside a function it would not have access to any variables that had not been passed into or created in the function (though I would have to think more about how shared variables work in this context.)