Задачи и отмена в .Net — tips & tricks

С выходом .NET Framework 4.0 в состав BCL была добавлена библиотека Task Parallel Library (TPL), реализующая параллелизм на основе задач. В основе библиотеки лежат типы Task и унаследованный от него тип Task<TResult>. Эти типы являются обёртками для асинхронных операций; они позволяют абстрагироваться от таких технических деталей, как, например, потоки и синхронизировать асинхронные операции друг с другом.

В этой же версии .NET Framework появился мини-framework для кооперативной отмены асинхронных операций. Состоит он из всего трёх типов:

• CancellationTokenSource — создаёт маркёры отмены (свойство Token) и обрабатывает запросы на отмену операции (перегруженные методы Cancel/CancelAfter).
• CancellationToken — маркёр отмены; позволяет несколькими способами отслеживать запросы на отмену операции: опросом свойства IsCancellationRequested, регистрацией callback-функции (через перегруженный метод Register), ожиданием на объекте синхронизации (свойство WaitHandle).
• OperationCanceledException — исключение, выброс которого по соглашению означает, что запрос на отмену операции был обработан и операция должна считаться отменённой. Предпочтительный способ генерации исключения — вызов метода CancellationToken. ThrowIfCancellationRequested.

Механизм отмены через CancellationToken является стандартным для TPL — есть перегрузки методов, принимающих CancellationToken, исключения OperationCanceledException специальным образом обрабатываются и т.д. Однако, как и в любом другом API, есть свои тонкости, хитрости, best practices.

Events vs. Rx

Есть замечательная библиотека «Reactive Extensions» (Rx) от Microsoft, которая предоставляет примитивы для реактивного программирования (в этой библиотеке вообще много всякого вкусного, но об этом как-нибудь в другой раз). В частности Rx позволяет представить .NET события в виде специальных коллекций — observable-коллекций. Такие коллекции представляют последовательность событий в виде потока данных. Самое замечательное, что с этими observable-коллекциями можно работать с помощью LINQ, так же как и с обычными коллекциями.

В этом посте я хочу сравнить два решения одной и той же задачи. Одна реализация строится на классических событиях; вторая — на observable-коллекциях из библиотеки Rx.

call vs. callvirt (часть 2)

Особенности инструкций call и callvirt, рассмотренные в предыдущей части, как правило, неинтересны разработчику на C#. Это детали реализации, про которые знать необязательно. Однако, в соответствии с законом Дырявых Абстракций, эти детали иногда всё-таки вылезают наружу.

call vs. callvirt (часть 1)

В процессе написания заметки про sealed-классы заинтересовался вопросом: «Влияет ли модификатор sealed на генерируемый компилятором IL-код вызова функций?». Любопытство завело меня довольно далеко; в этом посте — результаты моих изысканий на тему использования компилятором C# инструкций call и callvirt в генерируемом IL-коде.

Плохой код

Многие пишут в своих блогах про плохой код. Особенно интересно, когда этот код взят из реальных проектов — живые проблемы всегда интереснее. Я тоже решил в стороне не оставаться.

Про sealed-классы

В C# есть ключевое слово «sealed». Применяется оно в форме модификатора к классам, методам, свойствам и событиям, но сегодня речь пойдёт только про классы.

Что все знают про sealed-классы

Применительно к классу, модификатор sealed означает, что от класса нельзя наследоваться. Это правило проверяется на этапе компиляции — если попытаться отнаследоваться от sealed-класса код просто не будет компилироваться. По умолчанию модификатора sealed у класса нет, т.е. любой класс изначально может быть использован в качестве базового (разумеется, за исключением static-классов).