В чем преимущество использования async / await в сервисе win

Да, есть преимущество.

Представьте, что в вашем сервисе есть операция ввода/вывода, которая занимает 3 секунды для получения данных из какого-либо сокета. Использование шаблона Async/Await позволяет выполнять другие связанные с процессором работы за эти 3 секунды, не блокируя поток.

какой-то простой пример

var obj = new Demo();
var task1 = obj.WaitForIO(); //Imagine this as a database call that takes 5 seconds to finish
var task2 = obj.DoSomethingElse(); //Imagine this as some CPU bound work eg: some calculations
await Task.WhenAll(task1,task2);

public class Demo
{
    public async Task WaitForIO()
    {
        await Task.Delay(5000); 
        Console.WriteLine("IO Done");
    }

    public async Task DoSomethingElse()
    {
        for(var i=1;i<10;i++)
        {
            Console.WriteLine(i);
            await Task.Delay(1000);
        }
    }
}

Выход:

1
2
3
4
5
IO Done
6
7
8
9

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

async/await - освободить потоки. Одним из конкретных примеров этого является предотвращение замороженных пользовательских интерфейсов: async/await можно использовать для освобождения потока пользовательского интерфейса, чтобы он не был заморожен.

Существуют и другие сценарии, когда освобождение потоков полезно. Например, для веб-серверов освобождение потоков обеспечивает большую масштабируемость.

В некоторых случаях освобождение потоков не так полезно. Для настольных приложений иметь дополнительный поток (или десять) не так уж сложно, потому что большинство настольных компьютеров используются недостаточно. В частности, для консольных приложений вы хотите заблокировать основной поток, потому что в противном случае приложение завершит работу рано. Однако это не означает, что async не должна использоваться в консольных приложениях; Я иногда использую его только потому, что вы можете выполнять асинхронный параллелизм так же легко, как параллельный, особенно если API, которые вы вызываете, являются асинхронными.

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

Я хотел бы поделиться аналогиями, которые помогли мне понять преимущества асинхронного программирования. Надеюсь, что это поможет вам понять это, и вы увидите преимущество (если оно есть), которое вы можете иметь в вашем случае. Я узнал об этих аналогиях из ответа Эрика Липперта и Джона Скита С# в книге Глубины.

Представьте, что вам нужно выполнить 3 задания - поужинать, заполнить документы и постирать.

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

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

Обратите внимание, характер вашей работы важен. при заказе ужина и стирки, вы можете включить, и что-то/кто-то другой будет выполнять фактическую работу, пока вы ждете результата. это похоже на работу, связанную с вводом-выводом, в программировании, например, на вызов службы, вызов db и т.д. Где, когда вы пишете свою статью, именно вы действительно выполняете эту работу. Это похоже на работу, связанную с вычислениями в программировании, которая не очень хорошо подходит для асинхронного программирования.