Por que CancellationToken é separado de CancellationTokenSource?

Eu estou procurando uma justificativa do motivo pelo qual a CancellationTokenestrutura do .NET foi introduzida além da CancellationTokenSourceclasse. Entendo como a API deve ser usada, mas também quero entender por que ela foi projetada dessa maneira.

Ou seja, por que temos:

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

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

em vez de passar diretamente CancellationTokenSourcecomo:

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

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

Isso é uma otimização de desempenho com base no fato de que as verificações de estado de cancelamento ocorrem com mais frequência do que a transmissão do token?

Para que você CancellationTokenSourcepossa acompanhar e atualizar CancellationTokens, e para cada token a verificação de cancelamento é um acesso de campo local?

Dado que um bool volátil sem travamento é suficiente nos dois casos, ainda não consigo entender por que isso seria mais rápido.

Obrigado!

Eu estava envolvido no design e implementação dessas classes.

A resposta curta é " separação de preocupações ". É bem verdade que existem várias estratégias de implementação e que algumas são mais simples pelo menos no que diz respeito ao sistema de tipos e ao aprendizado inicial. No entanto, o CTS e o CT destinam-se ao uso em muitos cenários (como pilhas profundas de bibliotecas, computação paralela, assíncrona etc.) e, portanto, foram projetados com muitos casos de uso complexos em mente. É um design destinado a incentivar padrões bem-sucedidos e desencorajar anti-padrões sem sacrificar o desempenho.

Se a porta foi deixada aberta por APIs que se comportam mal, a utilidade do design de cancelamento pode ser rapidamente corroída.

CancellationTokenSource == "gatilho de cancelamento", além de gerar ouvintes vinculados

CancellationToken == "ouvinte de cancelamento"

Eu tinha a pergunta exata e queria entender a lógica por trás desse design.

A resposta aceita acertou na lógica. Aqui está a confirmação da equipe que criou esse recurso (ênfase minha):

Dois novos tipos formam a base da estrutura: A CancellationTokené uma estrutura que representa uma 'solicitação potencial de cancelamento'. Essa estrutura é passada para as chamadas de método como um parâmetro e o método pode pesquisá-lo ou registrar um retorno de chamada para ser acionado quando o cancelamento for solicitado. A CancellationTokenSourceé uma classe que fornece o mecanismo para iniciar uma solicitação de cancelamento e possui uma Token propriedade para obter um token associado. Teria sido natural combinar essas duas classes em uma, mas esse design permite que as duas operações principais (iniciar uma solicitação de cancelamento versus observar e responder ao cancelamento) sejam separadas adequadamente. Em particular, os métodos que usam apenas a CancellationTokenpodem observar uma solicitação de cancelamento, mas não podem iniciar uma.

Link: Estrutura de cancelamento do .NET 4

Na minha opinião, o fato de CancellationTokenapenas observar o estado e não alterá-lo é extremamente crítico. Você pode distribuir o token como um doce e nunca se preocupar que alguém, além de você, o cancele. Ele protege você contra código hostil de terceiros. Sim, as chances são pequenas, mas eu pessoalmente gosto dessa garantia.

Eu também sinto que isso torna a API mais limpa, evita erros acidentais e promove um melhor design de componentes.

Vamos dar uma olhada na API pública para essas duas classes.

Se você combiná-los, ao escrever LongRunningFunction, verei métodos como as várias sobrecargas de 'Cancel' que não devo usar. Pessoalmente, eu odeio ver o método Dispose também.

Eu acho que o design da classe atual segue a filosofia do 'poço do sucesso', orienta os desenvolvedores a criar melhores componentes que podem lidar com Task cancelamento e depois instrumentá-los juntos de várias maneiras para criar fluxos de trabalho complicados.

Deixe-me fazer uma pergunta, você já se perguntou qual é o objetivo do token. Não fazia sentido para mim. E então eu li Cancelamento em Threads Gerenciados e tudo ficou claro.

Acredito que o Projeto de Estrutura de Cancelamento no TPL é absolutamente de primeira.

Eles são separados não por razões técnicas, mas semânticas. Se você observar a implementação do CancellationTokenILSpy, verá que é apenas um invólucroCancellationTokenSource (e, portanto, não é diferente em termos de desempenho do que passar uma referência).

Eles fornecem essa separação de funcionalidade para tornar as coisas mais previsíveis: quando você passa um método a CancellationToken, sabe que ainda é o único que pode cancelá-lo. Certamente, o método ainda pode gerar um TaskCancelledException, mas o CancellationTokenpróprio - e quaisquer outros métodos que façam referência ao mesmo token - permanecerão seguros.

O CancellationTokené uma estrutura que muitas cópias podem existir devido à transmissão aos métodos.

Os CancellationTokenSourceconjuntos do estado de todos os exemplares de um símbolo quando chamando Cancela fonte.Veja esta página do MSDN

O motivo do design pode ser apenas uma questão de separação de preocupações e a velocidade de uma estrutura.

A CancellationTokenSourceé a 'coisa' que emite o cancelamento, por qualquer motivo. Ele precisa de uma maneira de 'despachar' esse cancelamento para todos os CancellationTokenque foi emitido. É assim que, por exemplo, o ASP.NET pode cancelar operações quando uma solicitação é abortada. Cada solicitação possui uma CancellationTokenSourceque encaminha o cancelamento a todos os tokens emitidos.

Isso é ótimo para testes de unidade BTW - crie sua própria fonte de token de cancelamento, obtenha um token, chame Cancela fonte e passe o token para o seu código que precisa lidar com o cancelamento.