Создание асинхронного метода в .NET 4.0, который можно использовать с "ожиданием" в .NET 4.5

У меня есть проект .NET, который использует С# в .NET 4.0 и VS2010.

Что я хотел бы сделать, так это добавить некоторые перегрузки асинхронов в мою библиотеку, чтобы сделать асинхронное программирование проще для пользователей в .NET 4.5 с ключевым словом ожидания. В настоящее время методы, которые перегружены, не являются асинхронными. Также я не хочу использовать какие-либо методы async, просто создаю новые и делаю их доступными.

Является ли создание async-методов в .NET 4.0 и VS2010 возможным, и если да, то каким должен выглядеть метод async.NET 4.0?

Поскольку я использую VS2010, у меня нет доступа к ключевому слову async, так что должно произойти, чтобы подражать этому поведению в .NET 4.0? Например, нужно ли возвращать какой-либо конкретный тип и должен ли выполняться какой-либо код внутри метода, чтобы сделать текущий неасинхронный код, который он вызывает, происходит асинхронно?

Ответ 1

Как утверждали другие, вы начинаете с того, что метод возвращает Task или Task<TResult>. Этого достаточно для await его результата в .NET 4.5.

Чтобы ваш метод вписывался как можно лучше с будущим асинхронным кодом, следуйте рекомендациям в документе Asynchronous Pattern на основе задач (также доступен в MSDN). Он обеспечивает соглашения об именах и рекомендации параметров, например, для поддержки отмены.

Для реализации вашего метода у вас есть несколько вариантов:

Если у вас есть существующие асинхронные методы на основе IAsyncResult, используйте Task.Factory.FromAsync.
Если у вас есть другая асинхронная система, используйте TaskCompletionSource<TResult>.

Ответ 2

Самый простой способ сделать это - вернуть Task или Task<T>. Этого будет достаточно.

Однако это имеет смысл только в том случае, если ваш метод действительно выполняется асинхронно.

Я также рекомендую вам следовать обычной схеме их обозначения как AbcAsync (суффикс "Async" ). Ваши абоненты не заметят никакой разницы в методе async, созданном с С# 5 (потому что его нет).

Совет. Просто добавление async в метод ничего не делает. Ваш метод будет выполняться последовательно и возвращать завершенную задачу. Приведение метода к возврату задачи должно служить определенной цели - обычно это делается потому, что метод по сути выполняется асинхронно (например, вызов веб-службы или файл IO).

Если ваш метод содержит только вычисления, но не IO (или только блокирование IO), обычно лучше не делать его асинхронным, потому что вы ничего не делаете. Асинхронные методы не всегда выполняются в отдельном потоке. Если это последнее предложение вас удивило, вам может понадобиться немного углубиться в эту тему.

Ответ 3

Пока вы возвращаете задачу, которая каким-то образом завершается (будь то в потоке или асинхронно), вы должны поддерживать асинхронную модель.

Выполнение асинхронной задачи - это еще одна история. Если у вас был доступ к ключевому слову async и API, вы могли бы просто основывать свой метод на асинхронных вызовах на другие, уже предоставленные методы async. Но в этом случае вы должны вручную обрабатывать свои асинхронные задачи.

Там могут быть лучшие способы сделать это, но самый элегантный способ, которым я могу видеть (и использовал), - использовать System.Threading.Tasks.TaskCompletionSource для построения задачи, использовать модель асинхронных методов Begin/End для выполнения все, что вам нужно выполнить. Затем, когда у вас есть результат под рукой, отправьте его в ранее построенный экземпляр Task, используя ваш источник завершения.

Это, безусловно, будет асинхронным, просто не таким же фантастическим, как в предстоящем выпуске.

Отказ от ответственности: Я не знаком с экспертом. Просто сделал несколько экспериментов.