MATLAB Answers

Whats the best command to write to file inside parfor loop?

140 views (last 30 days)
Chris on 22 Mar 2012
Edited: TOSA2016 on 10 Jul 2019
I want to write results to a file within a parfor loop and ideally append the results. What is the best command that can handle multiple writes potentially at the same time?

Accepted Answer

Edric Ellis
Edric Ellis on 23 Mar 2012
Inside PARFOR, you can still access the current task, and get its ID - that will be unique. My "Worker Object Wrapper" has an example how you could use that to open a file on each worker with a persistent file handle so that each worker can write its own file when executing a PARFOR loop.

  1 Comment

TOSA2016 on 10 Jul 2019
Thanks Edric for your resposne. I am just going to add some extra lines to it. In the new releases, worker object wrapper can be used by parallel.pool.Constant(). This is the code I used from mathwork web site (please click here ) to print line by line in parfor.
c = parallel.pool.Constant(@() fopen(tempname(pwd),'wt'),@fclose);
parfor idx = 1:1000
fprintf(c.Value,'Iteration: %d\n',idx);
clear c; % Closes the temporary files.
With this, you will ended up with several, depending on the number of workers, txt files with tempprary names that matlab chooses for them. Now, you would probably want to make them a single txt file. This is what I did inpired by the code posted (please click here).
for i = 1: length(A)
a= char(A(1,i));
NAMES(i,:) = a(1, length(pwd)+2:length(a));
for cntfiles=1:length(A)
fin=fopen(sprintf('%d.txt', cntfiles));
while ~feof(fin)
fprintf(fout,'%s \n',fgetl(fin));
% you can then delete the unnecesary files by the following loop
for i = 1:length(A)
For combining the txt files, I did not use the recommendations posted (please click here) since I faced several issues running the code on our cluster. It would be appreciated if someone can suggest a way to get rid of the while loop in the posted code.

Sign in to comment.

More Answers (4)

Jason Ross
Jason Ross on 22 Mar 2012
Multiple writes to the same file are a quick route to a corrupt file. You need to come up with a plan to assemble the file where only one write is done at a time. For example, you could write a collection of small files that are independently named and then have code that concatenates the data into the one result file.
The tempname function can return you a unique name, and then you can combine it with other information, such as hostname, lab index, time opened, etc to build up the filename.
When you are dealing with files you also need to make sure to pay attention to the return codes of fopen, fclose, etc. Duplicate filenames, read-only filesystems and full filesystems happen, and you should think about how you will handle these conditions when they occur.


Jeremy on 18 Jul 2014
I know this is an old thread...
Why couldn't I do something like
FileIDResults = -1;
while FileIDResults == -1
FileIDResults = fopen('projects_results.txt', 'a');
Wouldn't each worker then loop until it grabbed access to the file, lock the others out while it did it's fprintf, then free the file back up when it closed?
Edric Ellis
Edric Ellis on 21 Jul 2014
While that might work, you're somewhat at the mercy of the operating system as to whether it gives you exclusive write access; plus your results will come out in a non-deterministic order.

Sign in to comment.

Jill Reese
Jill Reese on 22 Mar 2012
If you are able to run your code inside an spmd block instead of via parfor, then you will be able to use the labindex variable to create a unique file name for each worker to write to. That is the best option.


Sign in to comment.

Konrad Malkowski
Konrad Malkowski on 22 Mar 2012
Are you planning on writing data from multiple workers to a single file within PARFOR? If so, then there are no commands that will allow you to do it.

  1 Comment

Sign in to comment.

Fernando García-García
Fernando García-García on 6 Dec 2014
Edited: Fernando García-García on 6 Dec 2014
Hello everyone,
Well, I'm planning to do what you said, Konrad. What if I do the following?
parfor i=1:N
% do something very time-comsuming, like hours or so
while checkIfOpen(filename)
pause(1); % i don't mind waiting for just 1 second
fprintf(fileID,...); % write whatever, very quick as it's not much data
function isOpen=checkIfOpen(filename)
for j=1:numel(openIDs)
if ~isempty(idxStrFind) % non empty
if idxStrFind(end)==size(filenameTEMP)-size(filename)+1
% found at the end of the entire path
isOpen = true;
Note 1: I don't mind if the writing is not in deterministic order.
Note 2: I would have never expected that, being such a long processing time for the task (and this time varying randomly from iteration to iteration somewhere in the range of minutes) compared to the very brief write operation (milliseconds)... that there was the enormous coincidence of two workers trying to write to file at the same time, but it did occur! Should have bought lottery, hehehe.
Note 3: Code corrected.
Note 4: I'm not sure how to actually check if this code behaves as expected.


Edric Ellis
Edric Ellis on 8 Dec 2014
Note that your checkIfOpen function will not work because each of the workers in the pool is a separate process - therefore the fopen('all') call will not return handles opened by the other workers.
In general, there is simply no robust way to have multiple workers write to a single file. If you're using Windows and all your workers are on the same machine, it might work to simply let each worker call fopen until it succeeds. I.e.
parfor idx = ...
fh = fopen(fname, 'a+');
while fh == -1
fh = fopen(fname, 'a+');
fprintf(fh, ...);
Here this relies on the behaviour that Windows filesystems typically don't allow multiple writers to the same file.
Fernando García-García
Fernando García-García on 8 Dec 2014
Thanks a lot, Edric!
You're completely right, the checkIfOpen didn't work: the concurrent writing happened again. A while ago I was thinking of using a global LOCK variable (this should be shared among workers, right?), but since (as you say) there is no robust way,... I'll have to find a workaround, perhaps using temporary files for each worker and assembling them once the parfor is finished.
Thanks again!
PS. I'm using Linux, but my workers are all in the same machine
Fernando García-García
Fernando García-García on 8 Dec 2014
Ok Edric, I found a post of yours in StackOverflow confirming that the approach based on global variables wouldn't have worked fine either.

Sign in to comment.

Sign in to answer this question.