Async-Await поток поведения и вопросы - PullRequest
0 голосов
/ 28 ноября 2018

Какая польза от метода асинхронного ожидания, который вызывает только один из методов асинхронного ожидания?Сколько потоков они охватывают?Сколько процессора вы можете потреблять?Привет, в последнее время я вижу много методов, использующих ключевые слова async и await.Я до сих пор не могу обернуться вокруг их использования и основного поведения, а также их преимущества при применении, как показано ниже.Я также заметил проблему с процессором (на 100%), когда они используют его для всего, и я вижу thread.run как виновника использования ЦП в некоторых из этих случаев.

myController.cs

[HttpPost]

[ProducesResponseType(body)]

public async Task<IActionResult> Post([FromBody]Body body){

_MyClassService.sendMessage(body);

return Ok(body);

}

Мой класс обслуживания

Myclass.cs

private async void sendMessage(){

await SendToProperChannel();

}



private async Task SendToProperChannel(){

await DoWorkInProperChannel();

}



private Task<int> DoWorkInProperChannel(){

await SomethingThatTakes5Seconds();

return 1+1;

}

По моим небольшим знаниям.

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

Мы также делаем все функции асинхронными, чтобы не блокировать верхние потоки, вызывающие эти методы.

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

Я до сих пор не знаю номер потока, но думаю, что мы создаем более 1 потока.выполнить один запрос.

Мои вопросы.

Какая польза от ожидания одного лайнера, если верхний метод не может продолжаться безответ?На самом деле API может получать большую пропускную способность, но с этого момента все будет синхронизировано, и порождение большего количества потоков только для того, чтобы переходить между методами в моем классе не кажется здоровым.

Если я только ждув одном конкретном коде, в этом конкретном коде результат не будет таким же, как удаление awaits?

Все методы также будут обрабатывать большую пропускную способность, так как они не блокируют, но также порождают больше потоков?

Как выглядит синтаксис для запуска асинхронного метода и ожидания ответа внутри одного и того же метода.

Пример:

private async Task<int> myAsyncWorkerMethod(){

var myNeededValue=methodThatINeed();

var mySecondValue=methodWithSecondValue();

await myNeededValue;

await mySecondValue;

return myNeededValue+mySecondValue;

}

ЧтоЯвляется ли преимущество асинхронным и ожидать от наличия только пула потоков, который обрабатывает все нисходящие вызовы, который вы можете легко контролировать его размер и легко обнаруживать голодание потока и глубину очереди?(Я мог бы использовать здесь некоторые Java-термины, которые могут не применяться)

Мысли

В других языках я видел последствия изменения контекста потока, если ваш процессорнедостаточно мощен или у вас истощение потоков из-за размера пула потоков, разве этот неконтролируемый пул потоков .net не будет иметь таких же последствий и будет просто использовать процессор столько, сколько он хочет?

Вы не делаетенужно создать асинхронный вызов, если вам нужно, чтобы он возвращал ответ для оператора await.делать асинхронный нужно только тогда, когда вам нужно поработать над вышеуказанным методом?

Даже если вы ожидаете результатов метода от другого класса, если вы не хотите блокировать основной поток, вы также не должны ждатьит.

Заранее спасибо

1 Ответ

0 голосов
/ 28 ноября 2018

Я постараюсь ответить на все ваши вопросы и вопросы сразу:

"Мы делаем запрос контроллера асинхронным, чтобы не блокировать основные потоки, что позволяет получить более высокую пропускную способность на контроллереуровень «.

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

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

Нет потока

«Я до сих пор не понимаю номер потока, но я считаю, что мы создаем более 1 потока для выполнения одного запроса».

Как уже упоминалось выше, это также недопустимо.

Какая польза от ожидания одного лайнера, если верхний метод не может продолжаться без ответа?

По сути, нет, код мог бы быть просто:

private async void sendMessage()
{    
    await DoWorkInProperChannel();
}

private Task<int> DoWorkInProperChannel()
{
    // `await Thread.Sleep()` is not valid, `Sleep` returns `void` 
    await Task.Delay(1000);

    return 1+1;
}

Примечание: ни один новый поток не создается из кода выше;не в оригинальной версии или в моей.

Если бы я ожидал только одного лайнера, в этом конкретном коде результат не был бы таким же, как удаление ожидающих?

Вовсе нет, вам нужно return Task, сгенерированный для того же кода.За исключением, конечно, метода async void, где вы ничего не можете вернуть.

private async Task<int> myAsyncWorkerMethod()
{
    var myNeededValue=methodThatINeed();
    var mySecondValue=methodWithSecondValue();
    await myNeededValue;
    await mySecondValue;

    return myNeededValue+mySecondValue;
}

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

В других языках я видел последствия изменения контекста потока, если ваш ЦП недостаточно мощный или у вас истощение потока, потому чторазмера пула потоков, разве этот неконтролируемый пул потоков .net не будет иметь таких же последствий и будет просто использовать процессор столько, сколько ему нужно?

Нет ни одного изменения контекста в коде, который выопубликовано, так что это не имеет значения.

Даже если вы ожидаете результатов метода из другого класса, если вы не хотите блокировать основной поток, вы также не должны его ждать.

Вы используете ASP.NET Core, нет основного потока.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...