为何使用CancellationTokenSource.Cancel的多线程代码无需过多防重排序措施

原因可以从两个维度解释：

• CancellationTokenSource的核心操作本身是线程安全的
  你调用的Cancel()方法内部已经实现了原子操作和必要的内存屏障，用来保证取消状态的修改对所有线程可见，也天然支持多线程同时调用——Cancel()是幂等操作，多次调用和单次调用的效果完全一致，不会抛出异常也不会产生额外副作用，不需要你在外部再加锁做同步。
• 当前场景不存在会引发错误的重排序风险
  你担心的指令重排序问题在这个示例里不会造成逻辑错误：
  1. source变量的初始化在所有子任务启动之前就已经完成，.NET的任务调度逻辑本身就自带内存屏障语义，保证子任务启动时能看到source的完整初始化结果，不会出现引用赋值重排序导致子任务拿到未初始化对象的问题。
  2. 就算存在局部指令重排序，最终的取消逻辑也不会受影响：只要触发了Cancel()调用，内部的内存屏障就会保证取消状态全局可见，无论哪个线程先调用、有没有重排序，最终的效果都是所有关联的令牌收到取消通知，完全符合预期。

另外补充说明：不是所有共享CancellationTokenSource的场景都不需要额外同步，如果你有在运行过程中修改source变量引用（比如把它赋值为新的对象、赋值为null）的需求，那还是需要加锁或者加volatile关键字保证可见性，这个示例里只对source做只读引用访问+调用线程安全的Cancel()方法，所以不需要额外防护。

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