2015-09-09 3 views
20

Так вот сценарий:Когда я «ждут» метод «асинхронный», он становится синхронным?

static async void Main(string[] args) 
{ 
    await AnAsyncMethod(); 
} 

private static async task<bool> AnAsyncMethod() 
{ 
    var x = await someAsyncMethod(); 
    var y = await someOtherAsyncMethod(); 

    return x == y; 
} 

Является ли «someAsyncMethod» и «someOtherAsyncMethod» работает синхронно, потому что мы используем Await, или они оба используют асинхронно в порядке, что их казнят?

UPDATE

Учитывая ответ ниже о том, что ожидало методы асинхронных будут выполняться последовательно, что бы цель создания этих вызовов асинхронной в первую очередь, если мы только собираемся остановить выполнение и ждать возвращаемых значений этого метода? Я видел, что в прошлом приложения для родных приложений ожидали/асинхронно, как средство освобождения потока пользовательского интерфейса, но есть ли другие причины, по которым этот дизайн был бы желателен?

+5

небольшой Sidenote 'Main' не может использовать' await' как его сам не отмечен как 'async' – Jamiec

+0

на вершине @Jamiec комментарий, если вы создаете еще один класс и поместить этот метод асинхронной в наличии, вы можете позвонить в вашем основном методе 'new SomeClass(). AnAsyncMethod.Wait();' и будет происходить асинхронно –

+1

Мое понимание заключается в том, что someAsyncMethod полностью завершит работу до того, как начнется процесс SomeAsyncMethod. – Biscuits

ответ

27

Они работают асинхронно, , но последовательно. someOtherAsyncMethod не будет вызываться до someAsyncMethod отделки.

Если вы хотите запустить их параллельно, у вас есть несколько вариантов

var taskA = MethodA(); 
var taskB = MethodB(); 

var a = await taskA; 
var b = await taskB; 

// or 

var results = await Task.WhenAll(MethodA(), MethodB()); 

последующий вопрос:

Я видел родные приложения в прошлом использования подстерегающие/async как средство освобождения потока пользовательского интерфейса, но есть ли другие причины, по которым этот дизайн был бы желателен?

В приложении ASP.NET, вы будете использовать это, чтобы текущий поток, чтобы вернуться к ThreadPool и обслуживать другие входящие запросы, в то время как MethodA/MethodB работают - если эти методы делают верно асинхронный ввод-вывод. В основном это единственная причина, почему вы делаете это в приложении ASP.NET.

Вы также можете прочитать Стивен Клири:

+2

Обратите внимание, что вы не можете использовать Task.WhenAll с mutliple вызовами EF в том же контексте. Это меня уже укусил. –

+4

И не только в ASP.NET - в любом многопользовательском серверном приложении вам будет полезно поддерживать низкий уровень потока. Каждый поток означает нецензурную память и использование ЦП - если у вас есть 4000 потоков, вы потеряли 4 гигабайта памяти (по крайней мере, как минимум, не заработали) только по стекам потоков по умолчанию. И так как вы только когда-либо действительно столько потоков, сколько у вас есть ядра процессора, дайте или возьмите, это совершенно ненужная трата. Это особенно верно в 32-битном приложении, где даже количество * виртуальной * памяти ограничено. – Luaan

+0

@ Luaan Спасибо за добавление, очень полезно! – dcastro

Смежные вопросы