Perché CancelToken è separato da CancelTokenSource?

Sto cercando una logica del perché .NET CancellationTokenstruct è stato introdotto oltre alla CancellationTokenSourceclasse. Capisco come utilizzare l'API, ma voglio anche capire perché è stato progettato in questo modo.

Cioè, perché abbiamo:

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

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

invece di passare direttamente in CancellationTokenSourcegiro come:

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

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

Si tratta di un'ottimizzazione delle prestazioni basata sul fatto che i controlli dello stato di annullamento si verificano più frequentemente rispetto al passaggio del token?

In modo che CancellationTokenSourcepossa tenere traccia e aggiornareCancellationTokens e per ogni token il controllo di annullamento è un accesso sul campo locale?

Dato che un bool volatile senza blocco è sufficiente in entrambi i casi, non riesco ancora a capire perché sarebbe più veloce.

Grazie!

Sono stato coinvolto nella progettazione e realizzazione di queste lezioni.

La risposta breve è " separazione delle preoccupazioni ". È vero che esistono varie strategie di implementazione e che alcune sono più semplici almeno per quanto riguarda il sistema dei tipi e l'apprendimento iniziale. Tuttavia, CTS e CT sono destinati all'uso in moltissimi scenari (come stack di librerie profonde, calcolo parallelo, asincrono, ecc.) E quindi sono stati progettati tenendo presenti molti casi d'uso complessi. È un progetto destinato a incoraggiare modelli di successo e a scoraggiare gli anti-schemi senza sacrificare le prestazioni.

Se la porta fosse lasciata aperta per le API che si comportavano male, l'utilità del progetto di annullamento potrebbe essere rapidamente erosa.

CancellationTokenSource == "trigger di annullamento", oltre a generare ascoltatori collegati

CancellationToken == "listener di annullamento"

Avevo la domanda esatta e volevo capire la logica alla base di questo progetto.

La risposta accettata ha ottenuto la logica esattamente corretta. Ecco la conferma del team che ha progettato questa funzione (enfasi sulla mia):

Due nuovi tipi formano la base del framework: A CancellationTokenè una struttura che rappresenta una "potenziale richiesta di cancellazione". Questa struttura viene passata nelle chiamate al metodo come parametro e il metodo può eseguire il polling su di esso o registrare un callback da attivare quando viene richiesta la cancellazione. A CancellationTokenSourceè una classe che fornisce il meccanismo per avviare una richiesta di annullamento e ha una Token proprietà per ottenere un token associato. Sarebbe stato naturale combinare queste due classi in una, ma questo progetto consente di separare in modo netto le due operazioni chiave (avvio di una richiesta di annullamento rispetto all'osservazione e risposta alla cancellazione). In particolare, i metodi che accettano solo a CancellationTokenpossono osservare una richiesta di annullamento ma non possono avviarne una.

Link: .NET 4 Framework di annullamento

Secondo me, il fatto che CancellationTokenpossa solo osservare lo stato e non cambiarlo, è estremamente critico. Puoi distribuire il token come una caramella e non preoccuparti mai che qualcun altro, diverso da te, lo annulli. Ti protegge dal codice di terze parti ostile. Sì, le possibilità sono scarse, ma personalmente mi piace quella garanzia.

Sento anche che rende l'API più pulita, evita errori accidentali e promuove una migliore progettazione dei componenti.

Diamo un'occhiata all'API pubblica per entrambe queste classi.

Se dovessi combinarli, quando scrivo LongRunningFunction, vedrò metodi come quei sovraccarichi multipli di 'Annulla' che non dovrei usare. Personalmente, odio vedere anche il metodo Dispose.

Penso che l'attuale design della classe segua la filosofia della "fossa del successo", guida gli sviluppatori a creare componenti migliori in grado di gestire la Taskcancellazione e quindi a strumentarli insieme in numerosi modi per creare flussi di lavoro complicati.

Lascia che ti faccia una domanda, ti sei mai chiesto qual è lo scopo del token. Non aveva senso per me. E poi ho letto Annullamento in Discussioni gestite e tutto è diventato cristallino.

Credo che il disegno del Framework di annullamento in TPL sia assolutamente di prim'ordine.

Sono separati non per motivi tecnici ma semantici. Se osservi l'implementazione di CancellationTokensotto ILSpy, scoprirai che è semplicemente un wrapper CancellationTokenSource(e quindi non è diverso dal punto di vista delle prestazioni rispetto al passare un riferimento).

Forniscono questa separazione di funzionalità per rendere le cose più prevedibili: quando passi un metodo a CancellationToken, sai di essere ancora l'unico che può annullarlo. Certo, il metodo potrebbe ancora lanciare un TaskCancelledException, ma lo CancellationTokenstesso - e qualsiasi altro metodo che fa riferimento allo stesso token - rimarrebbe al sicuro.

La CancellationTokenè una struttura così potrebbero esistere molte copie causa passando lungo ai metodi.

I CancellationTokenSourceImposta lo stato di tutte le copie di un gettone quando chiamata Cancelsulla fonte. Vedi questa pagina MSDN

Il motivo del design potrebbe essere solo una questione di separazione delle preoccupazioni e della velocità di una struttura.

La CancellationTokenSourceè la 'cosa' che le questioni della cancellazione, per qualsiasi motivo. Ha bisogno di un modo per "spedire" tale cancellazione a tutto CancellationTokenciò che ha emesso. Ecco come, ad esempio, ASP.NET può annullare le operazioni quando viene interrotta una richiesta. Ogni richiesta ha un CancellationTokenSourceche inoltra la cancellazione a tutti i token che ha emesso.

Questo è ottimo per i test di unità BTW: crea la tua sorgente token di annullamento, ottieni un token, chiama Cancell'origine e passa il token al tuo codice che deve gestire la cancellazione.