为什么 CancellationToken 与 CancellationTokenSource 是分开的？

Question

我正在寻找为什么除了CancellationTokenSource类之外还引入了 .NET CancellationToken结构的基本原理。 我了解如何使用 API，但也想了解为什么要这样设计。

即，为什么我们有：

var cts = new CancellationTokenSource();
SomeCancellableOperation(cts.Token);

...
public void SomeCancellableOperation(CancellationToken token) {
    ...
    token.ThrowIfCancellationRequested();
    ...
}

而不是直接传递CancellationTokenSource像：

var cts = new CancellationTokenSource();
SomeCancellableOperation(cts);

...
public void SomeCancellableOperation(CancellationTokenSource cts) {
    ...
    cts.ThrowIfCancellationRequested();
    ...
}

这是基于取消状态检查比传递令牌更频繁这一事实的性能优化吗？

以便CancellationTokenSource可以跟踪和更新CancellationTokens ，并且对于每个令牌，取消检查是本地字段访问？

鉴于在这两种情况下没有锁定的 volatile bool 就足够了，我仍然不明白为什么会更快。

谢谢！

Answer 1

我参与了这些类的设计和实现。

简短的回答是“关注点分离”。 确实存在各种实现策略，并且至少在类型系统和初始学习方面有些更简单。 但是，CTS 和 CT 旨在用于许多场景（例如深度库堆栈、并行计算、异步等），因此在设计时考虑了许多复杂的用例。 它的设计旨在鼓励成功的模式并在不牺牲性能的情况下阻止反模式。

如果对行为不端的 API 敞开大门，那么取消设计的用处可能很快就会被削弱。

CancellationTokenSource == "取消触发器"，加上生成链接的监听器

CancellationToken == “取消监听器”

Answer 2

我有确切的问题，我想了解这种设计背后的基本原理。

接受的答案完全正确。 这是设计此功能的团队的确认（重点是我的）：

两种新类型构成了该框架的基础： CancellationToken是一个表示“潜在取消请求”的结构。 此结构作为参数传递到方法调用中，该方法可以对其进行轮询或注册一个回调以在请求取消时触发。 CancellationTokenSource是一个提供发起取消请求机制的类，它有一个Token属性来获取关联的令牌。 将这两个类合二为一是很自然的，但这种设计允许两个关键操作（发起取消请求与观察和响应取消）完全分开。 特别是，仅采用CancellationToken可以观察取消请求，但不能发起取消请求。

链接：.NET 4 取消框架

在我看来， CancellationToken只能观察状态而不能改变状态这一事实非常关键。 您可以像分发糖果一样分发令牌，而不必担心除您之外的其他人会取消它。 它可以保护您免受恶意第三方代码的侵害。 是的，机会很小，但我个人喜欢这种保证。

我也觉得它使 API 更干净，避免了意外错误并促进了更好的组件设计。

让我们看看这两个类的公共 API。

如果您将它们组合起来，在编写 LongRunningFunction 时，我会看到诸如“取消”的多个重载之类的方法，我不应该使用这些方法。 就个人而言，我也讨厌看到 Dispose 方法。

我认为当前的类设计遵循“成功之坑”的理念，它指导开发人员创建更好的组件来处理Task取消，然后以多种方式将它们组合在一起以创建复杂的工作流。

我问你一个问题，你有没有想过token.Register的目的是什么？ 这对我来说没有意义。 然后我阅读了托管线程中的取消，一切都变得清晰起来。

我相信TPL中的取消框架设计绝对是一流的。

Answer 3

它们分开不是出于技术原因而是出于语义原因。 如果你看一下执行CancellationToken ILSpy下，你会发现它只是周围的包装CancellationTokenSource （因此没有什么不同性能方面比通过围绕基准）。

它们提供了这种功能分离以使事情更可预测：当您传递一个CancellationToken方法时，您知道您仍然是唯一可以取消它的人。 当然，该方法仍然可以抛出TaskCancelledException ，但CancellationToken本身——以及引用相同令牌的任何其他方法——将保持安全。

Answer 4

CancellationToken是一个结构体，因此由于将其传递给方法，因此可能存在许多副本。

CancellationTokenSource在对源调用Cancel时设置令牌的所有副本的状态。 请参阅此 MSDN 页面

设计的原因可能只是关注点分离和结构速度的问题。

Answer 5

CancellationTokenSource是发出CancellationTokenSource的“东西”，无论出于何种原因。 它需要一种方法将取消“调度”到它发出的所有CancellationToken 。 例如，这就是当请求中止时 ASP.NET 可以取消操作的方式。 每个请求都有一个CancellationTokenSource ，它将CancellationTokenSource转发给它发出的所有令牌。

这非常适合单元测试 BTW - 创建自己的取消令牌源，获取令牌，在源上调用Cancel ，并将令牌传递给必须处理取消的代码。

Answer 6

我的“理论”是CancellationToken的作用是提供一个线程安全的包装器来避免争用 。

如果只有一个类，那么一个唯一的实例将与引用副本一起使用，并且您有许多线程注册处理程序以进行取消，例如，此类应使用某些锁定来管理并发，从而降低性能。

而对于CancellationToken结构，您有每个线程的每个回调队列的副本，因此没有争用。

这是纯粹的猜测，我可能完全错误和/或这个设计可能有其他充分的理由。

唯一可以肯定的是，至少有一个很好的理由，而且这种决策没有更多的记录，因为它在使用技术时是一种宝贵的见解，这是一种遗憾。