Для начала разберемся с проблемой, а именно зачем нам нужна асинхронная модель и чем не устраивает синхронная.
Синхронная модель блокирует поток в ожидании результата ввода вывода (сеть, файловая система, etc. далее I/O), следовательно для того чтобы выполнить что-либо еще необходим отдельный поток. Таким образом узким местом данной модели являются потоки и переключение контекста потоков что является очень ресурсоемкой операцией.
В идеале неободимо чтобы в системе было столько рабочих потоков, сколько процессоров(ядер) в системе.
Асинхронная модель позволяет продолжить выполнение потока при операции I/O, и получить уведомление при завершении операции. Таким образом поток может выполнять полезную работу пока осуществяется I/O.
Отлично, теперь мы имеем представление о том что это и поэтому решаем использовать асинхронную модель как наиболее эффективную, но чем больше мы разбираемся с ней тем больше подводных камней встречаем.
Сложности асинхронной модели заключаются в создании понятного, логически последовательного кода, в структурном механизме обработки ошибок (ведь теперь про try/catch можно забыть). В результате имеем большое кол-во сложно отлавливаемых багов.
Как с этим бороться? Я попробую изложить свои концепции, которые зависят от платформы и языка программирования.
1) .NET — Самый простой и элегантный способ, на мой взгляд, могла бы реализовать .NET команда Microsoft. А именно, использовать волокна(fibers) для логических потоков в .NET. Волокна это легковесные объекты которые могли бы выполнять код, переключение между ними не ресурсоемко. Контроль кол-ва системных потоков а также переключение между волокнами должен осуществлять .NET Runtime. Реализовать это самостоятельно сложно, т.к. не документирована работа с логическими тредами в .NET Runtime.
В итоге программист бы использовал синхронную модель и ни о чем не задумывался, т.е. вместо блокировки потока произошла бы смена волокна для выполнения другой задачи.
2) С#.NET — Реализовать механизм, паттерн, при котором асинхронная модель имела бы также преимущества синхронной модели — логически последовательный код, механизм структурной обработки ошибок. Этот подход с примерами кода будет описан в следующей части.
3) С++ / Windows — Этот подход практически описан в пункте 1, т.е. необходимо использовать волокна для реализации поддержки асинхронной модели.
Описал кратко, надеюсь понятно и полезно.
Это моя первая статья на хабре, строго не судить ;)
Синхронная модель блокирует поток в ожидании результата ввода вывода (сеть, файловая система, etc. далее I/O), следовательно для того чтобы выполнить что-либо еще необходим отдельный поток. Таким образом узким местом данной модели являются потоки и переключение контекста потоков что является очень ресурсоемкой операцией.
В идеале неободимо чтобы в системе было столько рабочих потоков, сколько процессоров(ядер) в системе.
Асинхронная модель позволяет продолжить выполнение потока при операции I/O, и получить уведомление при завершении операции. Таким образом поток может выполнять полезную работу пока осуществяется I/O.
Отлично, теперь мы имеем представление о том что это и поэтому решаем использовать асинхронную модель как наиболее эффективную, но чем больше мы разбираемся с ней тем больше подводных камней встречаем.
Сложности асинхронной модели заключаются в создании понятного, логически последовательного кода, в структурном механизме обработки ошибок (ведь теперь про try/catch можно забыть). В результате имеем большое кол-во сложно отлавливаемых багов.
Как с этим бороться? Я попробую изложить свои концепции, которые зависят от платформы и языка программирования.
1) .NET — Самый простой и элегантный способ, на мой взгляд, могла бы реализовать .NET команда Microsoft. А именно, использовать волокна(fibers) для логических потоков в .NET. Волокна это легковесные объекты которые могли бы выполнять код, переключение между ними не ресурсоемко. Контроль кол-ва системных потоков а также переключение между волокнами должен осуществлять .NET Runtime. Реализовать это самостоятельно сложно, т.к. не документирована работа с логическими тредами в .NET Runtime.
В итоге программист бы использовал синхронную модель и ни о чем не задумывался, т.е. вместо блокировки потока произошла бы смена волокна для выполнения другой задачи.
2) С#.NET — Реализовать механизм, паттерн, при котором асинхронная модель имела бы также преимущества синхронной модели — логически последовательный код, механизм структурной обработки ошибок. Этот подход с примерами кода будет описан в следующей части.
3) С++ / Windows — Этот подход практически описан в пункте 1, т.е. необходимо использовать волокна для реализации поддержки асинхронной модели.
Описал кратко, надеюсь понятно и полезно.
Это моя первая статья на хабре, строго не судить ;)
