Почему существует CancellationTokenRegistration и почему он реализует IDisposable

Этот шаблон — удобный способ убедиться, что CancellationTokenRegistration.Unregister() вызывается автоматически. Его часто использует Стивен Тауб в своих сообщениях в блоге Параллельное программирование с .NET, например. здесь.

Я понимаю, что вы должны убедиться, что вы используете Dispose IDisposable, но почему он вообще реализует IDisposable? какие ресурсы он должен освободить? Единственные методы, которые у него есть, касаются равенства.

ИМО, лучший ответ на этот вопрос можно найти в . NET 4 Cancellation Framework сообщение Майка Лидделла из Microsoft:

Когда обратный вызов регистрируется для CancellationToken, текущий поток ExecutionContext захватывается, так что обратный вызов будет выполняться с точно таким же контекстом безопасности. Захват контекста синхронизации текущего потока является необязательным. При необходимости его можно запросить с помощью перегрузки ct.Register(). Обратные вызовы обычно сохраняются и затем запускаются при запросе отмены, но если обратный вызов регистрируется после запроса отмены, обратный вызов будет выполняться немедленно в текущем потоке или через Send() в текущем SynchronizationContext, если применимо.

Когда обратный вызов зарегистрирован для CancellationToken, возвращаемый объект является CancellationTokenRegistration. Это легкий тип структуры IDiposable, и удаление этого объекта регистрации приводит к отмене регистрации обратного вызова. Гарантируется, что после возврата метода Dispose() зарегистрированный обратный вызов не будет запущен и впоследствии не запустится. Следствием этого является то, что CancellationTokenRegistration.Dispose() должен блокироваться, если обратный вызов выполняется в данный момент. Следовательно, все зарегистрированные обратные вызовы должны быть быстрыми и не блокироваться на какое-либо значительное время.

Другой соответствующий документ Майка Лидделла: «Использование поддержки отмены в .NET Framework 4» (UsingCancellationinNET4.pdf).

Обновлено, это можно проверить здесь, в справочнике Источник.

Также важно отметить, что обратный вызов отмены регистрируется с помощью CancellationTokenSource, а не CancellationToken. Таким образом, если область действия CancellationTokenRegistration.Dispose() определена неправильно, регистрация останется активной в течение всего времени существования родительского объекта CancellationTokenSource. Это может привести к неожиданному обратному вызову, когда область действия асинхронной операции исчерпана, например:

async Task TestAsync(WebClient wc, CancellationToken token)
{
    token.Register(() => wc.CancelAsync());
    await wc.DownloadStringAsync(new Uri("http://www.hamster.com"));
}

// CancellationTokenSource.Cancel() may still get called later,
// in which case wc.CancelAsync() will be invoked too

Таким образом, важно ограничить одноразовый CancellationTokenRegistration с помощью using (или явно вызвать CancellationTokenRegistration.Dispose() с помощью try/finally).

почему он вообще реализует IDisposable? какие ресурсы он должен освободить?

IDisposable часто используется для вещей, совершенно не связанных с высвобождением ресурсов; это удобный способ убедиться, что что-то будет сделано в конце блока using, даже если возникнет исключение. Некоторые люди (не я) утверждают, что это злоупотребление шаблоном Dispose.

В случае CancellationToken.Register «что-то» — это отмена регистрации обратного вызова.

Обратите внимание, что в коде, который вы разместили в своем вопросе, использование блока using для CancellationTokenRegistration почти наверняка является ошибкой: поскольку wc.DownloadStringAsync возвращается немедленно, обратный вызов будет немедленно отменен, прежде чем операция сможет быть отменена. , поэтому wc.CancelAsync никогда не будет вызываться, даже если CancellationToken сигнализируется. Было бы разумно, если бы вызов wc.DownloadStringAsync ожидался, потому что в этом случае конец блока using не был бы достигнут до завершения wc.DownloadStringAsync. (EDIT: больше не верно, так как вопрос был отредактировано)

Что произойдет, если вы не избавитесь от него? что ты сливаешь?

В этом случае происходит то, что обратный вызов не является незарегистрированным. Вероятно, это не имеет большого значения, потому что на него ссылается только токен отмены, а поскольку CancellationToken — это тип значения, который обычно хранится только в стеке, ссылка исчезнет, ​​когда выйдет за пределы области видимости. Таким образом, в большинстве случаев ничего не произойдет, но это может произойти, если вы сохраните CancellationToken где-то в куче. EDIT: на самом деле это неправильно; см. ответ Нозерацио для объяснения