Mutex for Increment in Matlab Parfor?
显示 更早的评论
I am trying to use Matlab's parfor for the following code:
parfor j=1:10
if (vtw(dta{j},A2,Mu2,Sigma2,A5,Mu5,Sigma5)==1)
results(1,1)=results(1,1)+1;
end
end
Matlab doesn't like this code saying parfor cannot be used because of the way results is being used.
To me this is a bit confusing as in C++ I would consider this a very separable operation and simply insert a mutex around the results++ (which doesn't really need one as increments are atomic). How do I fix this?
采纳的回答
Edric Ellis
2012-3-26
It's only the indexing into results that PARFOR doesn't understand. The following should work I think:
results = 0;
parfor j=1:10
if (vtw(dta{j},A2,Mu2,Sigma2,A5,Mu5,Sigma5)==1)
results = results + 1;
end
end
5 个评论
Mikhail Kandel
2012-3-26
Mikhail Kandel
2012-3-26
Edric Ellis
2012-3-26
PARFOR analyses your code before execution, and it doesn't consider "results(1,1)" to be a valid target for a reduction.
Abel
2013-6-25
so parfor will actively prevent the race-condition??
Edric Ellis
2013-6-26
There is no race condition - PARFOR understands the reduction using '+' and how to perform that in parallel.
更多回答（3 个）
Walter Roberson
2012-3-25
parfor j = 1 : 10
results_j(j) = vtw(dta{j},A2,Mu2,Sigma2,A5,Mu5,Sigma5)==1;
end
results = sum(results_j);
3 个评论
Mikhail Kandel
2012-3-25
Geoff
2012-3-25
Even in C/C++, I would have a preference for Walter's solution over one that uses calls to the kernel.
Walter Roberson
2012-3-26
Misha, sorry, I do not have the appropriate toolbox to test this code, so I cannot say why MATLAB might not like it. If you post the error message someone might recognize it. Might be something as simple as initializing results_j ahead of time.
owr
2012-3-26
Be careful using if statements without matching elses inside parfor loops. Ive experienced some strange behaviour in both 2011a and 2011b when this is done with linear indexing.
This example is a bit contrived, but it illustrates the issue:
matlabpool open;
[x,y] = meshgrid(1:10,1:10);
results = nan(10);
parfor i =1:100
if( x(i) <= y(i) )
results(i) = 2;
end
end
>> results
results =
2 0 0 0 0 0 NaN NaN NaN NaN
2 2 0 0 0 0 NaN NaN NaN NaN
2 2 2 0 0 0 NaN NaN NaN NaN
2 2 2 2 0 0 NaN NaN NaN NaN
2 2 2 2 2 0 0 NaN NaN NaN
2 2 2 2 2 2 0 0 NaN NaN
2 2 2 2 2 2 2 0 NaN NaN
2 2 2 2 2 2 2 2 0 NaN
2 2 2 2 2 2 2 2 2 0
2 2 2 2 2 2 2 2 2 2
Where did the zeros come from?
1 个评论
Edric Ellis
2012-3-27
Hm, that looks like a bug. Thanks for reporting this.
Jan
2012-3-25
When different PARFOR loops process this line:
results(1,1) = results(1,1) + 1;
The following can happen:
- Thread 1: results(1,1) is evaluated and stored temporarily
- Thread 2: 1 is added to the temporary variable
- Thread 2: results(1,1) is evaluated and stored temporarily
- Thread 1: results(1,1) is updated
- Thread 2: results(1,1) is updated
Now the results(1,1) is increased by 1, and not by 2. This happens because there is no mutex to block simultaneous access to result.
If the increment is atomic, there would be no need to implement InterlockedIncrement(). While the 32 bit increment is usually atomic on modern compilers and processors, this is not guaranteed for 64 bit types as int64 and doubles. Using a critical section is recommended, or InterlockedIncrement().
1 个评论
Edric Ellis
2012-3-26
Actually, PARFOR understands various reduction operations by taking advantage of the mathematical properties of the expression. So, this addition can be done, but the syntax needs tweaking.
类别
在 帮助中心 和 File Exchange 中查找有关 Parallel for-Loops (parfor) 的更多信息
2012-3-25
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
Translated by 
