使用Interlocked.Exchange写入后volatile读取是否存在线程安全问题？

首先看目标代码：

class TaskTracker
{
    private volatile ConcurrentBag<Task> _bag = new();
    
    public async Task WaitAllAvailableAsync()
    {
        await Task.WhenAll(Interlocked.Exchange(ref _bag, new()));
    }

    public void AddTask(Task toWait)
    {
        // should guarantee that the Task will be awaited on at least one WaitAllAvailableAsync call
        ConcurrentBag<Task> oldBag, bag = _bag;
        do
        {
            bag.Add(toWait);
            oldBag = bag;
        } while ((bag = _bag) != oldBag);
    }
}

这个类的核心逻辑是：WaitAllAvailableAsync通过原子操作替换任务袋，等待所有旧任务；AddTask尝试将任务加入当前袋，确保任务至少被一次等待操作覆盖。

核心疑问解答 #

1. Volatile读取能否确保看到Interlocked.Exchange后的新值？ #

在.NET的内存模型中，volatile字段的读取属于获取操作（Acquire），写入属于释放操作（Release）：

• 读取volatile字段时，CPU会直接从主内存获取最新值，不会依赖本地缓存的过期数据；
• 同时禁止读取操作与后续指令重排序，确保读取到的是所有线程已提交的写入结果。

而Interlocked.Exchange是一个带全内存屏障的原子操作，它的写入会立即同步到主内存。因此，当Exchange完成后，任何后续对_bag的volatile读取一定会看到新的引用实例，不存在“延迟看不到新值”的情况——volatile的语义已经完全保障了读取的新鲜度。

2. 当前代码是否存在线程安全问题？会不会有任务永远不被等待？ #

不存在任务永远不被等待的场景，理由如下：

• AddTask的循环逻辑：每次将任务加入当前拿到的bag后，会重新读取_bag。如果此时_bag已被Exchange替换（新旧bag实例不同），循环会继续，将任务再次加入新的bag。
• 无论极端情况如何：
  • 如果任务被加到旧bag，这个旧bag已经被Exchange取走，会被正在执行的WaitAllAvailableAsync等待；
  • 如果任务被加到新bag，后续的WaitAllAvailableAsync一定会处理这个新bag。
• 由于volatile读取的保障，循环最终一定会终止（当某次读取的bag和上次的oldBag一致时），此时任务已经被加到当前有效的bag中，必然会被后续的等待操作处理。

唯一的小问题是：极端情况下任务可能被多次添加到不同的bag中，导致被等待多次。但这不符合“任务仅被等待一次”的预期，不过这不属于“永远不被等待”的问题，也和volatile的行为无关。

3. 用Interlocked.CompareExchange(ref _bag, null, null)替代volatile读取是否更好？ #

两者的语义保障是一致的：都能确保读取到主内存的最新值，且带有内存屏障禁止重排序。但从性能角度看：

• Volatile读取是用户态操作，仅需轻量级的内存栅栏，开销极低；
• Interlocked.CompareExchange是内核态操作，需要CPU总线锁，开销更大。

因此，当前场景下使用volatile读取已经足够，不需要替换成Interlocked.CompareExchange。

内容的提问来源于stack exchange，提问作者Vlad