Interlocked.CompareExchange 初始值的指令重新排序
Interlocked.CompareExchange instruction reodering of the initialvalue
我想知道是否可以将以下代码中的初始值重新排序为在计算之后导致未定义的行为。
public class ThreadSafe
{
// Field totalValue contains a running total that can be updated
// by multiple threads. It must be protected from unsynchronized
// access.
private float totalValue = 0.0F;
// The Total property returns the running total.
public float Total { get { return totalValue; }}
// AddToTotal safely adds a value to the running total.
public float AddToTotal(float addend)
{
float initialValue, computedValue;
do
{
// Save the current running total in a local variable.
initialValue = totalValue;
//Do we need a memory barrier here??
// Add the new value to the running total.
computedValue = initialValue + addend;
// CompareExchange compares totalValue to initialValue. If
// they are not equal, then another thread has updated the
// running total since this loop started. CompareExchange
// does not update totalValue. CompareExchange returns the
// contents of totalValue, which do not equal initialValue,
// so the loop executes again.
}
while (initialValue != Interlocked.CompareExchange(ref totalValue,
computedValue, initialValue));
// If no other thread updated the running total, then
// totalValue and initialValue are equal when CompareExchange
// compares them, and computedValue is stored in totalValue.
// CompareExchange returns the value that was in totalValue
// before the update, which is equal to initialValue, so the
// loop ends.
// The function returns computedValue, not totalValue, because
// totalValue could be changed by another thread between
// the time the loop ends and the function returns.
return computedValue;
}
}
在将 totalvalue 赋给 initialvalue 和实际计算之间是否需要内存屏障?
正如我目前所理解的那样,可以在没有障碍的情况下以消除导致线程安全问题的初始值的方式进行优化,因为计算值可以使用陈旧值进行计算,但 CompareExchange 将不再检测到这一点:
public float AddToTotal(float addend)
{
float computedValue;
do
{
// Add the new value to the running total.
computedValue = totalValue + addend;
// CompareExchange compares totalValue to initialValue. If
// they are not equal, then another thread has updated the
// running total since this loop started. CompareExchange
// does not update totalValue. CompareExchange returns the
// contents of totalValue, which do not equal initialValue,
// so the loop executes again.
}
while (totalValue != Interlocked.CompareExchange(ref totalValue,
computedValue, totalValue));
// If no other thread updated the running total, then
// totalValue and initialValue are equal when CompareExchange
// compares them, and computedValue is stored in totalValue.
// CompareExchange returns the value that was in totalValue
// before the update, which is equal to initialValue, so the
// loop ends.
// The function returns computedValue, not totalValue, because
// totalValue could be changed by another thread between
// the time the loop ends and the function returns.
return computedValue;
}
这里是否缺少局部变量的特殊规则来解释为什么示例不使用内存屏障?
A CPU 永远不会 "reorders" 可能影响 single-threaded 执行逻辑的指令。万一
initialValue = totalValue;
computedValue = initialValue + addend;
第二个操作肯定是依赖于上一个操作设置的值。 CPU "understands" 从它的 single-threaded 逻辑角度来看,所以这个序列永远不会被重新排序。但是可以重新排序以下序列:
initialValue = totalValue;
anotherValue = totalValue;
或
varToInitialize = someVal;
initialized = true;
如您所见,single-core 执行不会受到影响,但在多核上这可能会带来一些问题。例如,如果我们围绕这样一个事实构建我们的逻辑,即如果变量 initialized
设置为 true
那么 varToInitialize
应该用某个值初始化,我们可能会在 multi-core 上遇到麻烦环境:
if (initialized)
{
var storageForVal = varToInitialize; // can still be not initalized
...
// do something with storageForVal with assumption that we have correct value
}
至于局部变量。重新排序的问题是全局可见性的问题,即一个 core/CPU 对另一个 cores/CPUs 所做的更改的可见性。局部变量主要倾向于只对单线程可见(除了一些罕见的情况,比如闭包,在方法之外公开的情况下实际上不是局部变量)所以其他线程无法访问它们并且因此其他 cores/CPUs 不需要他们的全球知名度。所以换句话说,在绝大多数情况下你不需要担心局部变量操作重新排序。
我想知道是否可以将以下代码中的初始值重新排序为在计算之后导致未定义的行为。
public class ThreadSafe
{
// Field totalValue contains a running total that can be updated
// by multiple threads. It must be protected from unsynchronized
// access.
private float totalValue = 0.0F;
// The Total property returns the running total.
public float Total { get { return totalValue; }}
// AddToTotal safely adds a value to the running total.
public float AddToTotal(float addend)
{
float initialValue, computedValue;
do
{
// Save the current running total in a local variable.
initialValue = totalValue;
//Do we need a memory barrier here??
// Add the new value to the running total.
computedValue = initialValue + addend;
// CompareExchange compares totalValue to initialValue. If
// they are not equal, then another thread has updated the
// running total since this loop started. CompareExchange
// does not update totalValue. CompareExchange returns the
// contents of totalValue, which do not equal initialValue,
// so the loop executes again.
}
while (initialValue != Interlocked.CompareExchange(ref totalValue,
computedValue, initialValue));
// If no other thread updated the running total, then
// totalValue and initialValue are equal when CompareExchange
// compares them, and computedValue is stored in totalValue.
// CompareExchange returns the value that was in totalValue
// before the update, which is equal to initialValue, so the
// loop ends.
// The function returns computedValue, not totalValue, because
// totalValue could be changed by another thread between
// the time the loop ends and the function returns.
return computedValue;
}
}
在将 totalvalue 赋给 initialvalue 和实际计算之间是否需要内存屏障?
正如我目前所理解的那样,可以在没有障碍的情况下以消除导致线程安全问题的初始值的方式进行优化,因为计算值可以使用陈旧值进行计算,但 CompareExchange 将不再检测到这一点:
public float AddToTotal(float addend)
{
float computedValue;
do
{
// Add the new value to the running total.
computedValue = totalValue + addend;
// CompareExchange compares totalValue to initialValue. If
// they are not equal, then another thread has updated the
// running total since this loop started. CompareExchange
// does not update totalValue. CompareExchange returns the
// contents of totalValue, which do not equal initialValue,
// so the loop executes again.
}
while (totalValue != Interlocked.CompareExchange(ref totalValue,
computedValue, totalValue));
// If no other thread updated the running total, then
// totalValue and initialValue are equal when CompareExchange
// compares them, and computedValue is stored in totalValue.
// CompareExchange returns the value that was in totalValue
// before the update, which is equal to initialValue, so the
// loop ends.
// The function returns computedValue, not totalValue, because
// totalValue could be changed by another thread between
// the time the loop ends and the function returns.
return computedValue;
}
这里是否缺少局部变量的特殊规则来解释为什么示例不使用内存屏障?
A CPU 永远不会 "reorders" 可能影响 single-threaded 执行逻辑的指令。万一
initialValue = totalValue;
computedValue = initialValue + addend;
第二个操作肯定是依赖于上一个操作设置的值。 CPU "understands" 从它的 single-threaded 逻辑角度来看,所以这个序列永远不会被重新排序。但是可以重新排序以下序列:
initialValue = totalValue;
anotherValue = totalValue;
或
varToInitialize = someVal;
initialized = true;
如您所见,single-core 执行不会受到影响,但在多核上这可能会带来一些问题。例如,如果我们围绕这样一个事实构建我们的逻辑,即如果变量 initialized
设置为 true
那么 varToInitialize
应该用某个值初始化,我们可能会在 multi-core 上遇到麻烦环境:
if (initialized)
{
var storageForVal = varToInitialize; // can still be not initalized
...
// do something with storageForVal with assumption that we have correct value
}
至于局部变量。重新排序的问题是全局可见性的问题,即一个 core/CPU 对另一个 cores/CPUs 所做的更改的可见性。局部变量主要倾向于只对单线程可见(除了一些罕见的情况,比如闭包,在方法之外公开的情况下实际上不是局部变量)所以其他线程无法访问它们并且因此其他 cores/CPUs 不需要他们的全球知名度。所以换句话说,在绝大多数情况下你不需要担心局部变量操作重新排序。