User`s guide

8 Program Communicating Jobs
8-10
Further Notes on Communicating Jobs
In this section...
“Number of Tasks in a Communicating Job” on page 8-10
“Avoid Deadlock and Other Dependency Errors” on page 8-10
Number of Tasks in a Communicating Job
Although you create only one task for a communicating job, the system copies this task
for each worker that runs the job. For example, if a communicating job runs on four
workers, the Tasks property of the job contains four task objects. The first task in the
job’s Tasks property corresponds to the task run by the worker whose labindex is 1,
and so on, so that the ID property for the task object and labindex for the worker that
ran that task have the same value. Therefore, the sequence of results returned by the
fetchOutputs function corresponds to the value of labindex and to the order of tasks
in the job’s Tasks property.
Avoid Deadlock and Other Dependency Errors
Because code running in one worker for a communicating job can block execution until
some corresponding code executes on another worker, the potential for deadlock exists in
communicating jobs. This is most likely to occur when transferring data between workers
or when making code dependent upon the labindex in an if statement. Some examples
illustrate common pitfalls.
Suppose you have a codistributed array D, and you want to use the gather function to
assemble the entire array in the workspace of a single worker.
if labindex == 1
assembled = gather(D);
end
The reason this fails is because the gather function requires communication between
all the workers across which the array is distributed. When the if statement limits
execution to a single worker, the other workers required for execution of the function are
not executing the statement. As an alternative, you can use gather itself to collect the
data into the workspace of a single worker: assembled = gather(D, 1).