是“种族状况”并行代码会产生与顺序不同的唯一原因？
我的功能是，当我在w/ diff输入中并行运行它时，输出与使用相同的输入顺序运行时的输出不同。
种族条件是发生这种情况的唯一原因吗？
编辑：我尝试了以下操作 - 我以相同的输入并行运行3个版本的函数，。这3个输出完全相同，但它们与我在没有并行化的代码时仍然不同。所以..这意味着“种族条件”不是问题，对吗？否则3个结果会有所不同吗？
I have a function that, when I run it in parallel w/ diff inputs, gives a different output than when I run it sequentially with those same inputs.
Is a race condition the only reason this would happen?
EDIT: I have tried the following - I run 3 versions of the function in parallel, all with the same input. The 3 outputs are exactly the same, but they are still different than when I run the code without parallelization. So.. that means a "race condition" is not the issue, right? Otherwise the 3 results would be different?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
no ，与顺序相比，种族条件并不是唯一导致结果不同的原因。有很多可能的原因。并行性的一个常见问题是，操作的顺序已修改。事情并不是所有的操作都是关联或交换性的。例如，浮点操作不是关联（例如
（1 + 1e-16）-1e-16！= 1 +（1e-16-16-1e-16）对于IEEE-754 64位浮点数）。这意味着，平行总和通常不会给出相同的结果（有趣的点：平行的总和通常会更准确，因此不同的并不意味着错误）。矩阵乘法在理论上是关联的，但不是交换性的（由于FP非缔合性，实际上它们既不是联想性的也不是合理性的）。基于随机的算法（例如蒙特卡洛）可以在每个线程中使用不同的种子，从而导致相同的统计行为，但结果不同（由于不同的随机序列）。没有提到其他错误可以出现在并行实现中（通常是 不确定的行为）。No, race conditions are not the only possible reason causing different results compared to the sequential one. There are plenty of possible reasons. One frequent issue with parallelism is that the order of the operations is modified. The thing is not all operations are associative or commutative. For example, floating-point operations are not associative (eg.
(1 + 1e-16) - 1e-16 != 1 + (1e-16 - 1e-16)for IEEE-754 64-bit floating-point numbers). This means, a parallel sum will generally not gives the same results than a sequential one (funny point: the parallel one will often be slightly more accurate, so different does not mean wrong). Matrix multiplications are theoretically associative but not commutative (due to FP non-associativity, they are in fact neither associative nor commutative). Random-based algorithms (eg Monte-Carlo) can use a different seed in each thread generally resulting to the same statistical behaviour but different results (due to a different random sequence). Not to mentions that other bugs can appear in a parallel implementation (typically undefined behaviours).