Чому ви коли-небудь «чекаєте» методу, а потім негайно допитуєте його повернену вартість?

У цій статті MSDN наведено наступний приклад коду (трохи відредагований для стислості):

public async Task<ActionResult> Details(int? id)
{
    if (id == null)
    {
        return new HttpStatusCodeResult(HttpStatusCode.BadRequest);
    }

    Department department = await db.Departments.FindAsync(id);

    if (department == null)
    {
        return HttpNotFound();
    }

    return View(department);
}

FindAsyncМетод повертає Departmentоб'єкт по його ID, і повертає Task<Department>. Потім відділ негайно перевіряється, чи є він нульовим. Як я розумію, запит на значення Завдання таким чином заблокує виконання коду, поки значення з очікуваного методу не повернеться, фактично зробивши це синхронним викликом.

Навіщо ти коли-небудь це робив? Чи не було б простіше просто викликати синхронний метод Find(id), якщо ви все одно негайно заблокуєте?

Як я розумію, запит на значення Завдання таким чином заблокує виконання коду, поки значення з очікуваного методу не повернеться, фактично зробивши це синхронним викликом.

Не зовсім.

Після виклику await db.Departments.FindAsync(id)завдання відсилається, а поточний потік повертається в пул для використання в інших операціях. Потік виконання блокується (як це було б незалежно від використання departmentвідразу після того, як я все зрозумів правильно), але сам потік вільний для використання іншими речами, поки ви чекаєте завершення операції поза машиною (і сигналізується портом події або завершення).

Якщо ви зателефонували, d.Departments.Find(id)то нитка все-таки сидить там і чекає відповіді, хоча більша частина обробки виконується в БД.

Ви ефективно звільняєте ресурси процесора під час зв’язування диска.

Я дуже ненавиджу, що жоден із прикладів не показує, як можна почекати кілька рядків, перш ніж чекати завдання. Розглянемо це.

Foo foo = await getFoo();
Bar bar = await getBar();

Console.WriteLine(“Do some other stuff to prepare.”);

doStuff(foo, bar);

Це такий тип коду, який заохочують приклади, і ви маєте рацію. У цьому мало сенсу. Основна тема дозволяє безкоштовно робити інші речі, як-от відповідь на введення інтерфейсу користувача, але реальна сила асинхронізації / очікування - я можу легко продовжувати робити інші речі, поки я чекаю завершення потенційно тривалого завдання. Код вище буде "блокований" і чекатиме виконання лінії друку, поки ми не отримаємо Foo & Bar. Не потрібно чекати, хоча. Ми можемо це обробити, поки будемо чекати.

Task<Foo> foo = getFoo();
Task<Bar> bar = getBar();

Console.WriteLine(“Do some other stuff to prepare.”);

doStuff(await foo, await bar);

Тепер, за допомогою переписаного коду, ми не зупиняємось і чекаємо своїх значень, поки не доведеться. Я завжди придивляюся до таких можливостей. Розумність, коли ми очікуємо, може призвести до значного покращення продуктивності. У нас сьогодні декілька ядер, можемо також їх використовувати.

Тож тут відбувається більше, що відбувається за лаштунками. Async / Await - синтаксичний цукор. Спочатку подивіться на підпис функції FindAsync. Він повертає завдання. Вже зараз ви бачите магію ключового слова, воно розкриває завдання в відділ.

Функція виклику не блокується. Що трапляється, це те, що присвоєння відділу та все, що слідує за ключовим словом, що очікує, потрапляють у закрите, а всі наміри та цілі передаються методу Task.ContinueWith (функція FindAsync автоматично виконується в іншому потоці).

Звичайно, є більше, що трапляється за кадром, тому що операція перенесена на початковий потік (тому вам більше не доведеться турбуватися про синхронізацію з інтерфейсом користувача при виконанні фонової операції) і якщо функція виклику Async ( і називаються асинхронно) те саме відбувається в стеку.

Тож, що трапляється, ви отримуєте магію операцій Async, без підводних каменів.

Ні, це не повертається відразу. Очікування робить виклик методу асинхронним. Коли викликається FindAsync, метод Details повертається із завданням, яке не закінчено. Коли FindAsync закінчиться, він поверне свій результат у змінну відділу та відновить решту методу Details.

Мені подобається думати про "асинхронізацію", як про контракт, про контракт, в якому сказано: "Я можу виконати це асинхронно, якщо вам це потрібно, але ви також можете зателефонувати мені, як і будь-яка інша синхронна функція".

Це означає, що один розробник робив функції, і деякі дизайнерські рішення спонукали їх робити / позначати купу функцій як "асинхронізацію". Абонент / споживач функцій може вільно користуватися ними за рішенням. Як ви говорите, ви можете або зателефонувати в очікуванні безпосередньо перед викликом функції, і чекати його, таким чином ви поставилися до нього як до синхронної функції, але якщо ви цього хотіли, можете зателефонувати, не чекаючи, як

Task<Department> deptTask = db.Departments.FindAsync(id);

і після, скажімо, 10 рядків вниз функції, яку ви викликаєте

Department d = await deptTask;

отже, трактуйте це як асинхронну функцію.

Тобі вирішувати.

"якщо ви все-таки негайно заблокуєте", відповідь - "Так". Тільки тоді, коли вам потрібна швидка реакція, чекати / асинхронізувати сенс. Наприклад, потік користувальницького інтерфейсу прийшов до дійсно асинхронного методу, потік інтерфейсу повернеться і продовжить слухати клацання кнопки, тоді як код нижче "очікувати" буде виправданий іншим потоком і нарешті отримає результат.