Файл: Асинхронноепрограммирование.pdf

77
Исключения в async-методах, возвращающих Task async Task Catcher()
{
try
{
await Thrower();
}
catch (AlexsException)
{
// Исключение будет обработано здесь
}
}
async Task Thrower()
{
await Task.Delay(100);
throw new AlexsException();
}
До тех пор пока исполнение не дошло до первого await, синхронный стек вызовов и цепочка асинхронных методов ничем не отличаются. Поведение исключений в этой точке несколько изменено ради согласованности, но это изменение гораздо более скромное.
Для этого C# перехватывает все исключения, возникшие в вашем async-методе. Перехваченное исключение помещается в объект
Task
, который был возвращен вызывающей программе. Объект
Task переходит в состояние Faulted. Если задача завершилась с ошибкой, то ожидающий ее метод не возобновится как обычно, а получит исключение, возбужденное в коде внутри await
Исключение, повторно возбужденное оператором await
, – это тот же самый объект, который был порожден в предложении throw
. По мере того как он распространяется вверх по стеку вызовов, растет ас- социированная с ним трассировка стека. Это может показаться стран- ным тому, кто пробовал повторно возбуждать исключение вручную, например в написанном вручную асинхронном коде. Дело в том, что здесь используется новая возможность типа .NET
Exception
Ниже приведен пример трассировки стека для цепочки из двух async-методов. Мой код выделен полужирным шрифтом.
System.NullReferenceException: Object reference not set to an instance of an object.
at FaviconBrowser.MainWindow.d__c.MoveNext() in
MainWindow.xaml.cs:line 74
--- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at

78
Глава 9. Исключения в асинхронном коде
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotifi cation(T
ask task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at FaviconBrowser.MainWindow.d__0.MoveNext() in
MainWindow.xaml.cs:line 41
--- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.AsyncMethodBuilderCore.b__0(Object state)
at ... Методы каркаса
Упоминание метода
MoveNext связано с преобразованием кода, осуществляемым компилятором (см. главу 14). Мои методы пере- межаются методами каркаса, но тем не менее можно получить пред- ставление о том, какая последовательность моих методов привела к исключению.
Незамеченные исключения
Одно из важных различий между синхронным и асинхронным ко- дом – место, где возбуждается исключение, возникшее в вызванном методе. В async-методе оно возбуждается там, где находится оператор await
, а не в точке фактического вызова метода. Это становится оче- видным, если разделить вызов и await
// Здесь AlexsException никогда не возбуждается
Task task = Thrower();
try
{
await task;
}
catch (AlexsException)
{
// Исключение обрабатывается здесь
}
Очень легко забыть о необходимости ожидать завершения async- метода, особенно если тот возвращает объект неуниверсального класса
Task
, потому что программе не требуется значение результа- та. Но поступить таким образом – все равно, что включить пустой блок catch
, который перехватывает и игнорирует все исключения.
Это плохое решение, потому что может привести к некорректному состоянию программы и к тонким ошибкам, проявляющимся далеко от места возникновения. Возьмите за правило всегда ожидать завер- шения любого async-метода, если не хотите потом провести долгие часы в обществе отладчика.

79
Выстрелил и забыл
Такое игнорирование исключений – новшество, появившееся в
.NET после включения механизма async. Если вы ожидаете, что исключение, возникшее в библиотечном коде Task Parallel Library, будет повторно возбуждено в потоке финализатора, то имейте в виду – в .NET 4.5 этого уже не происходит.
Исключения в методах типа
async void
Ждать с помощью await завершения async-метода, возвращающего void
, невозможно, поэтому его поведение в части исключений долж- но быть другим. Заведомо не хотелось бы, чтобы исключения, воз- буждаемые такими методами, оставались незамеченными. А хотим мы, чтобы исключение, покинувшее метод типа async void
, было повторно возбуждено в вызывающем потоке:
• если в месте, где был вызван async-метод, существовал кон- текст синхронизации
SynchronizationContext
, то исключе- ние посылается ему методом
Post
;
• в противном случае оно возбуждается в потоке, взятом из пула.
В большинстве случаев обе ситуации приводят к завершению про- цесса, если только к соответствующему событию не присоединен об- работчик необработанных исключений. Маловероятно, что вас это устроит, и именно по этой причине методы типа async void следует писать, только если они будут вызываться из внешнего кода или если можно гарантировать отсутствие исключений.
Выстрелил и забыл
Редко, но бывают ситуации, когда неважно, как завершился метод, а ждать его завершения слишком сложно. В таком случае я рекомен- дую все же возвращать объект
Task
, но передавать его методу, спо- собному обработать исключения. Лично мне нравится такой метод расширения:
public static void ForgetSafely(this Task task)
{
task.ContinueWith(HandleException);
}

80
Глава 9. Исключения в асинхронном коде
Здесь метод
HandleException передает любое исключение систе- ме протоколирования, как, например, в разделе «Создание собствен- ных комбинаторов» выше.
AggregateException и WhenAll
В асинхронных программах приходится иметь дело с ситуацией, ко- торая в синхронном коде вообще невозможна. Метод может возбуж- дать сразу несколько исключений. Так бывает, например, когда мы используем метод
Task.WhenAll для ожидания завершения группы асинхронных операций. Ошибкой могут завершиться несколько опе- раций, причем ни одну ошибку нельзя считать первой или самой важ- ной.
Метод
WhenAll
– всего лишь наиболее распространенный меха- низм, приводящий к возникновению нескольких исключений, но существует немало других способов параллельного выполнения нескольких операций. Поэтому поддержка множественных исклю- чений встроена непосредственно в класс
Task
. Исключение в нем представляется объектом класса
AggregateException
, а не просто
Exception
. Объект
AggregateException содержит коллекцию дру- гих исключений.
Поскольку эта поддержка встроена в класс
Task
, то когда исклю- чение покидает async-метод, создается объект
AggregateException и фактическое исключение добавляется в него как внутреннее пе- ред помещением в
Task
. Таким образом, в большинстве случаев
AggregateException содержит только одно внутреннее исключение, но метод
WhenAll создает
AggregateException с несколькими ис- ключениями.
Все это происходит вне зависимости от того, произошло ли ис- ключение до первого await или позже. Исключения, имевшие место до первого await, легко можно было бы возбудить синх- ронно, но тогда они возникали бы при вызове метода, а не в ре- зультате await в вызывающей программе, что было бы непосле- довательно.
С другой стороны, если исключение повторно возбуждается оператором await
, нам необходим какой-то компромисс. Оператор await должен возбуждать исключение того же типа, что было изна- чально возбуждено в async-методе, а не типа
AggregateException
Поэтому ничего не остается, кроме как возбудить первое внутреннее

81
Синхронное возбуждение исключений исключение. Однако, перехватив его, мы можем обратиться к объек- ту
Task напрямую и получить от него объект
AggregateException
, содержащий полный список исключений.
Task allTask = Task.WhenAll(tasks);
try
{
await allTask;
}
catch
{
foreach (Exception ex in allTask.Exception.InnerExceptions)
{
// Обработать исключение
}
}
Синхронное возбуждение
исключений
Паттерн TAP допускает синхронное возбуждение исключений, но только если исключение служит для индикации ошибок в порядке вызова метода, а не ошибок, возникающих в процессе его выполнения.
Мы видели, что async-метод перехватывает любое исключение и по- мещает его в объект
Task
, вне зависимости от того, произошло оно до или после первого await
. Поэтому если вы хотите возбудить исклю- чение синхронно, то придется прибегнуть к трюку: воспользоваться синхронным методом, который проверяет ошибки перед вызовом асинхронного.
private Task GetFaviconAsync(string domain)
{
if (domain == null) throw new ArgumentNullException(“domain”);
return GetFaviconAsyncInternal(domain);
}
private async Task GetFaviconAsyncInternal(string domain)
{
Получающуюся при таком подходе трассировку стека интерпре- тировать немного проще. Стоит ли овчинка выделки? Лично я сомне- ваюсь. Тем не менее, этот пример полезен для лучшего понимания.

82
Глава 9. Исключения в асинхронном коде
Блок finally в async-методах
Наконец, в async-методе разрешено использовать блок try-fi nally
, и работает он в основном, как и ожидается. Гарантируется, что блок fi nally будет выполнен до того, как программа покинет содержащий его метод, неважно произошло это в ходе нормального выполнения или в результате исключения внутри блока try
Но эта гарантия таит в себе скрытую опасность. В случае async-ме- тода нет гарантии, что поток выполнения вообще когда-либо покинет метод. Легко написать метод, который доходит до await
, приостанав- ливается, а затем про него забывают, и в конечном итоге он достается сборщику мусора.
async void AlexsMethod()
{
try
{
await DelayForever();
}
fi nally
{
// Сюда мы никогда не попадем
}
}
Task DelayForever()
{
return new TaskCompletionSource

ГЛАВА 10.
Организация параллелизма
с помощью механизма
async
Механизм async открывает широкие возможности для использования параллелизма, характерного для современных машин. Это языковое средство позволяет структурировать программу гораздо проще, чем было возможно раньше.
Мы уже видели, как пишется простой код, запускающий несколь- ко длительных операций, например сетевых запросов, которые затем исполняются параллельно. Благодаря таким средствам, как
WhenAll
, асинхронный код весьма эффективен для выполнения подобных опе- раций, не связанных с локальными вычислениями. Если же речь идет о локальных вычислениях, то сам по себе механизм async не поможет.
Пока не достигнута точка асинхронности, весь код выполняется син- хронно в вызывающем потоке.
await и блокировки
Простейший способ распараллелить программу состоит в том, что за- планировать работу в разных потоках. Это легко сделать с помощью метода
Task.Run
, так как он возвращает объект
Task
, с которым мы можем обращаться, как с любой другой длительной операцией. Но наличие нескольких потоков сопряжено с риском небезопасного до- ступа к разделяемым объектам в памяти.
Традиционное решение, заключающееся в использовании ключе- вого слова lock
, в асинхронном коде более сложно, о чем мы говори- ли в разделе «Блоки lock» выше. Поскольку в блоке lock нельзя ис- пользовать оператор await
, то не существует способа предотвратить исполнение конфликтующего кода во время ожидания. На самом

84
Глава 10. Организация параллелизма с помощью...
деле, лучше вообще избегать удержания ресурсов на время исполне- ния await
. Весь смысл асинхронности как раз и состоит в том, чтобы освобождать ресурсы на время ожидания, и программист должен по- нимать, что в это время может произойти всё что угодно.
lock (sync)
{
// Подговиться к асинхронной операции
}
int myNum = await AlexsMethodAsync();
lock (sync)
{
// Использовать результат асинхронной операции
}
Рассмотрим в качестве примера поток пользовательского интер- фейса. Такой поток существует в единственном экземпляре, поэтому в некотором смысле его можно считать блокировкой. Если некий код работает в потоке пользовательского интерфейса, то в каждый момент времени заведомо выполняется только одна его команда. Но даже в этом случае во время ожидания может случиться всё что угодно.
Если в ответ на нажатие пользователем кнопки вы запускаете сетевой запрос, то ничто не помешает пользователю нажать ту же кнопку еще раз, пока ваша программа ждет результата. В этом и состоит смысл асинхронности в приложениях с пользовательским интерфейсом: ин- терфейс остается отзывчивым и делает всё, что просит пользователь, даже если это опасно.
Но мы по крайней мере можем указать в программе точки, в кото- рых могут происходить неприятности. Следует взять за правило ста- вить await только в местах, где это безопасно, и быть готовым к тому, что после возобновления состояние мира может измениться. Иногда это означает, что необходимо произвести вторую, кажущуюся бес- смысленной, проверку, прежде чем продолжать работу.
if (DataInvalid())
{
Data d = await GetNewData();
// Внутри await могло произойти всё что угодно if (DataInvalid())
{
SetNewData(d);
}
}

85
Акторы
Я сказал, что поток пользовательского интерфейса можно рассмат- ривать, как блокировку, просто потому что такой поток всего один.
На самом деле, было бы правильно назвать его актором. Актор – это поток, который отвечает за определенный набор данных, причем ни- какой другой поток не вправе обращаться к этим данным. В данном случае только поток пользовательского интерфейса имеет доступ к данным, составляющим пользовательский интерфейс. При таком подходе становится гораздо проще обеспечить безопасность кода пользовательского интерфейса, потому что единственное место, где что-то может произойти, – это await
Если говорить более общо, то программы можно строить из ком- понентов, которые работают в одном потоке и отвечают за опреде- ленные данные. Такая модель акторов легко адаптируется к парал- лельным архитектурам, так как акторы могут работать на разных ядрах. Она эффективна и в программах общего вида, когда имеются компоненты, наделенные состоянием, которым требуется безопасно манипулировать.
Существуют и другие парадигмы, например программирование потоков данных (dataflow programming), чрезвычайно эффектив- ные в естественно параллельных (embarrassingly parallel) задачах, когда имеется много независимых друг от друга вычис- лений, допускающих очевидное распараллеливание. Акторы – подходящий выбор для тех задач, где очевидного распараллели- вания не существует.
На первый взгляд, между программированием с помощью акторов и с помощью блокировок очень много общего. В частности, в обоих моделях присутствует идея о том, что в каждый момент времени до- ступ к определенным данным разрешен только одному потоку. Раз- ница же в том, что один поток не может принадлежать сразу несколь- ким акторам. Вместо того чтобы удерживать ресурсы одного актора на время выполнения кода другого актора, поток должен сделать асинхронный вызов. Во время ожидания вызывающий поток может заняться другими делами.
Модель акторов лучше масштабируется, чем модель программиро- вания с блокировками разделяемых объектов. Модель, основанная на доступе к общему адресному пространству из нескольких ядер, посте- пенно отдаляется от реальности. Если вам доводилось использовать в программе блокировки, то вы знаете, как просто «нарваться» на взаи- моблокировки и состояния гонки.
Акторы

86
Глава 10. Организация параллелизма с помощью...
Использование акторов в C#
Конечно, никто не мешает программировать в стиле модели акто- ров вручную, но есть и библиотеки, упрощающие эту задачу. Так, библиотека NAct (http://code.google.com/p/n-act/) в полной мере задействует механизм async в C# для превращения обычных объектов в акторов, в результате чего все обращения к ним производятся в отдельном потоке. Достигается это с помощью заместителя, который обертывает объект, делая его актором.
Рассмотрим пример. Пусть требуется реализовать криптографи- ческую службу, которой для шифрования потока данных необходима последовательность псевдослучайных чисел. Здесь имеются две зада- чи, требующие большого объема вычислений, и мы хотели бы решать их параллельно:
• генерация псевдослучайных чисел;
• использование их для потокового шифрования.
Мы будем рассматривать только актора, играющего роль генера- тора случайных чисел. Библиотеке NAct необходим интерфейс, имея который она сможет создать для нас заместителя. Реализуем этот интерфейс:
public interface IRndGenerator : IActor
{
Task GetNextNumber();
}
Этот интерфейс должен наследовать пустому маркерному интер- фейсу
IActor
. Все методы интерфейса должны возвращать один из совместимых с механизмом async типов:
• void
•
Task
•
Task
Теперь можно реализовать сам класс генератора.
class RndGenerator : IRndGenerator
{
public async Task GetNextNumber()
{
// Безопасная генерация случайного числа – медленная операция return num;
}
}

87
Библиотека Task Parallel Library Dataflow
Неожиданно здесь только то, что никаких неожиданностей нет.
Это самый обычный класс. Чтобы им воспользоваться, мы должны сконструировать объект и передать его NAct, чтобы та обернула его, превратив в актора.
IRndGenerator rndActor = ActorWrapper.WrapActor(new RndGenerator());
Task nextTask = rndActor.GetNextNumber();
foreach (var chunk in stream)
{
int rndNum = await nextTask;
// Начать генерацию следующего числа nextTask = rndActor.GetNextNumber();
// Использовать rndNum для шифрования блока – медленная операция
}
На каждой итерации цикла я жду случайного числа, а затем запус- каю процедуру генерации следующего, пока сам занимаюсь медлен- ной операцией. Поскольку rndActor
– актор, NAct возвращает объект
Task немедленно, а генерацию производит в потоке
RndGenerator
Теперь два вычисления осуществляются параллельно, что позволяет лучше использовать ресурсы процессора. Благодаря встроенному в язык механизму async трудная задача программирования выражает- ся очень естественно.
Здесь не место вдаваться в детали работы с библиотекой NAct, но надеюсь, я рассказал достаточно для понимания того, насколько прос- то использовать модель акторов. У нее есть и другие возможности, в частности генерация событий в нужном потоке и интеллектуальное разделение потоков между простаивающими акторами. В общем и целом это означает, что модель хорошо масштабируется в реальных системах.
Библиотека Task Parallel Library
Dataflow
Еще одно полезное средство параллельного программирования, ис- пользование которого в C# упрощается за счет применения механиз- ма async, – это парадигма программирования потоков данных. В этой модели определяется последовательность операций, которые необ- ходимо произвести над входными данными, а система автоматичес-

88
Глава 10. Организация параллелизма с помощью...
ки распараллеливает их. Microsoft предлагает для этой цели библи- отеку TPL Dataflow, которую можно скачать из репозитория NuGet
(https://nuget.org/packages/Microsoft.Tpl.Dataflow).
Техника программирования потоков данных особенно полезна, когда самой критичной с точки зрения производительности час- тью программы является преобразование данных. Ничто не ме- шает одновременно использовать акторов и программирование потоков данных. В этом случае один актор, на который приходит- ся большой объем вычислений, применяет для их распаралле- ливания потоки данных.
Идея библиотеки TPL Dataflow заключается в передаче сообще- ний между блоками. Чтобы создать сеть потоков данных, мы сцепля- ем блоки, реализующие два интерфейса:
ISourceBlock
Нечто такое, у чего можно запросить сообщения типа
T.
ITargetBlock
Нечто такое, чему можно передать сообщения.
В интерфейсе
ISourceBlock определен метод
LinkTo
, который принимает объект-получатель типа
ITargetBlock
и связывает его с источником, так что каждое сообщение, порожденное объектом
ISourceBlock
, передается объекту
ITargetBlock
. Большинст- во блоков реализуют оба интерфейса, быть может, с разными пара- метрами-типами, так чтобы блок мог потреблять сообщения одного типа и порождать сообщения другого типа.
Интерфейсы можно реализовывать самостоятельно, но гораздо чаще используются встроенные блоки, например:
ActionBlock
Конструктору объекта
ActionBlock
передается делегат, который вызывается для каждого сообщения. Класс
Acti- onBlock реализует только интерфейс
ITargetBlock
TransformBlock
Конструктору также передается делегат, только на этот раз он является функцией, возвращающей значение. Это значение становится сообщением, которое передается следующему бло- ку. Класс
TransformBlock
реализует интерфейсы
ITargetBlock и
ISourceBlock
. Это параллель- ная версия LINQ-метода
Select

89
Библиотека Task Parallel Library Dataflow
JoinBlock
Объединяет несколько входных потоков в один выходной по- ток, состоящий из кортежей.
Есть много других встроенных блоков, из которых можно конст- руировать вычисление конвейерного типа. Без дополнительного программирования блоки работают как параллельный конвейер, но каждый блок способен одновременно обрабатывать только одно сообщение. Этого достаточно, если все блоки работают примерно одинаковое время, но если какая-то стадия оказывается существен- но медленнее всех остальных, то можно сконфигурировать объекты
ActionBlock
и
TransformBlock
, так чтобы они ра- ботали параллельно в отдельном блоке, то есть по сути дела расщеп- ляли себя на много идентичных блоков, которые сообща трудятся над некоторой задачей.
Библиотека TPL Dataflow получает выигрыш от механизма async, потому что делегаты, передаваемые блокам
ActionBlock
и
TransformBlock
, могут быть асинхронными и возвра- щать значения типа
Task или
Task соответственно. Это особенно важно, когда указанные делегаты выполняют длительные удаленные операции, потому что их можно запускать параллельно, не занимая зря потоки. Кроме того, взаимодействие с блоками потоков данных извне также полезно организовывать асинхронно, и для облегчения этой задачи существуют такие TAP-методы, как
SendAsync
, расши- ряющий класс
ITargetBlock