giá trị Vector khác nhau nếu truy cập bên ngoài hoặc từ bên trong parfor

Question

Tôi đã tạo thử nghiệm này Matlab script file:

numbers = [29 37 44 54 62]; 

for i=1:length(numbers) 
    fprintf('%d\n', numbers(i)); 
end 

fprintf('***\n'); 

matlabpool local 5; 
parfor i=1:length(numbers) 
    fprintf('%d\n', numbers(i)); 
end % image loop 
fprintf('***\n') 
for i=1:length(numbers) 
    fprintf('%d\n', numbers(i)); 
end 
matlabpool close; 

fprintf('***\n'); 

for i=1:length(numbers) 
    fprintf('%d\n', numbers(i)); 
end 

Khi tôi chạy nó, tôi nhận được liên tục cho kết quả sau:

29 
37 
44 
54 
62 
*** 
112 
111 
107 
117 
115 
*** 
29 
37 
44 
54 
62 
*** 
29 
37 
44 
54 
62 

Các fprintf trong khối parfor in các tập số dường như ngẫu nhiên, tuy nhiên, luôn luôn giống nhau (112, 111, 107, 117, 115). Bất kỳ ý tưởng nào về lý do tại sao điều này đang xảy ra?

CẬP NHẬT

Điều thú vị đủ, điều này chỉ xảy ra nếu tôi chạy kịch bản từ dòng lệnh:

matlabR2012b -nodesktop -nosplash -nodisplay -r "run parfortest.m; exit" 

Nếu đầu tiên tôi mở một phiên Matlab và chạy parfortest ở đó, sau đó những con số được in đúng.

Answer 1

Đây là vấn đề cụ thể về chạy chứ không phải vấn đề về nodesktop. Để xác minh điều này, bạn có thể thử

>> run parfortest.m 

từ máy tính để bàn MATLAB và bạn sẽ tìm thấy cùng một đầu ra.

Mặc dù đây không phải là giải pháp như vậy; nếu bạn bỏ qua chạy và chỉ sử dụng

>> parfortest 

kết quả xấu sẽ được sửa.

Answer 2

Tôi đoán bạn không thể thực sự viết song song một tệp. Hoặc trong trường hợp này màn hình đầu ra vì fprintf ("văn bản") ngụ ý fprintf (1, "văn bản") trong đó 1 là tệp ID cho màn hình đầu ra.

Tệp này hiện đang được sửa đổi bởi nhiều quy trình là một vấn đề vì bộ đệm được sử dụng không bị xóa trước khi các thao tác khác bắt đầu và hành vi sẽ không chính xác.

Có thể this liên kết sẽ trợ giúp.

Answer 3

Tôi cũng có thể sao chép nó trên OS X, R2012b. Trong mex, mexPrintf không phải là thread safe. Xem this. Tôi sẽ không ngạc nhiên nếu Matlab's fprintf dựa trên mexPrintf - hoặc mã tương tự - dưới mui xe. Nếu bạn biến tập lệnh của mình thành một hàm - chỉ cần đặt function parfortest trên dòng đầu tiên - sự cố sẽ biến mất, do đó, nó cũng có thể là vấn đề phạm vi.

EDIT: Thử in nhiều hơn năm số, giả sử 12 số. Bây giờ, hãy sử dụng char để chuyển đổi các giá trị này thành ký tự ASCII. Dường như, trong vòng parfor vòng fprintf đang in ra đường dẫn đến tệp bạn đã chạy qua lệnh Terminal (một số hình thức parfortest.m theo thứ tự ngẫu nhiên - tôi chạy tệp từ ~/Desktop/parfortest.m và chuyển đổi số từ fprintf thành ký tự tôi nhận được D/~ksepotap/frroetst.m). Nếu bạn cố in nhiều giá trị hơn chiều dài của đường dẫn thì bạn sẽ gặp lỗi. Tôi không thể tìm thấy một cách giải quyết khác hơn là biến kịch bản của bạn thành một hàm (đó là một ý tưởng tốt dù sao). Chắc chắn có vẻ như một lỗi.