Whats the best command to write to file inside parfor loop?
조회 수: 111(최근 30일)
Edric Ellis 2012년 3월 23일
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.
Jason Ross 2012년 3월 22일
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.
Jill Reese 2012년 3월 22일
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.
Konrad Malkowski 2012년 3월 22일
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.
Fernando García-García 2014년 12월 6일
편집: Fernando García-García 2014년 12월 6일
Well, I'm planning to do what you said, Konrad. What if I do the following?
% do something very time-comsuming, like hours or so
pause(1); % i don't mind waiting for just 1 second
fprintf(fileID,...); % write whatever, very quick as it's not much data
if ~isempty(idxStrFind) % non empty
% 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.