OSDev

Кто как реализует асинхронные вызовы? Типичным назначением асинхронного вызова это вызов колбек функции.
Если такая функция по пробует получить доступ к данным. То состояние этих данных должно быть определено.

Как это решается при параллельном программировании? Решается это при помощи механизмов синхронизации по данным: мьютексы и запоры(Lock).

Отсюда вывод параллельное выполнение привело бы к тому, что все данные надо будет оборачивать в защитные механизмы и программирование в общем случае усложняется.
Так разумеется никто не делает. В место этого используется корпоративная многозадачность.
Как это сделано в POSIX? Практически все системные вызовы перед тем как начать работать по своему алгоритму проверяют нет ли асинхронных сигналов и если есть выполняют их и вываливаются с ошибкой EINTR. А если нет, то выполняют свой алгоритм.
Как это сделано в Windows? Передача в асинхронные вызовы идёт только при проверке очереди сообщений и ожиданий событий.
Для стандартного ввода/вывода предусмотрены какие-то слабо документированные пути, которые решают частные проблемы.
Суть в том что в STD для Cx11 по попросту создаёт параллельный поток в котором и проверяется очередь сообщений. От чего уходили к тому и вернулись. Понимаете что процессы синхронизации там сделаны через одно место.

Зачем нужны асинхронные вызовы? К примеру что-бы прервать долгие функцииалгоритмы такие как чтение большого файла или потока. Послать сигнал завершения работы, для корректной остановки приложения.
Таймер, который желательно иметь с гарантированными интервалами во времени. Ещё для оптимизации механизмов синхронизаций по событиям и времени(wait* - функции). С другой стороны больше я и не знаю для чего. Есть ли другие области которые я забыл?

Ещё FlowControl. Некоторые его разновидности управляют синхронизацией передачи данных через дополнительные сигнальные линии. Я сейчас говорю не только про RS232. Но и про именованные каналы, консольный ввод/вывод, потоки, файлы, сокеты.


Это было предисловие. Теперь вопрос, а как бы вы реализовали всю эту машинерию? Как по мне что в POSIX что в WinAPI это сделано крайне неудобно.

Для этого есть соисполняемые процедуры (coroutines) и соответствующие операторы (запросить результат или переключиться на другую ожидающую процедуру), см. yield from в питоне и await в C#. Если смотреть на системный API, то для того чтобы помочь в реализации асинхронщины есть хорошие linux-specific системные вызовы, такие как epoll и signalfd.

Вопрос не о том как сделать это внутри функции. Это просто вызов пары функций и флаг для сохранения состояния - что прячется под синтаксическим сахаром yield или await или под epoll.
Вопрос в другом, что со стороны прикладного программиста это ужас. В POSIX эта просто перекладывается на прикладного программиста, который просто забивает на всё это. А в виндоусе по сути не работает. Либо переходим на событийную модель как любом фремворке, но по сути это не решает проблем. А только их прячет.

Пара интересных статей на эту тему:
https://habrahabr.ru/post/201826/
https://habrahabr.ru/company/yandex/blog/240525/

Такой вопрос делаю свой ЯП задумался а нужно делать
Signal и slot как в QT. Вопрос в том не будет ли это тормозить? И вообще это нормально ведь по идее тут можно в каждую функцию вставить ответвление на асинхронную обработку. Таким образом число вызовов асинхронных методов можно повысить до 1 миллиона в секунду.
Меня смущает количество.

ИМХО - не очень.
Для каждой сопрограммы нужен свой стек, его нужно выделать при вызове и отслеживать (например ставя в конце guard page) или делать заведомо огромных размеров, как сделано в предложенных статьях и вообще почти во всех реализациях, про которые я читал - тогда он будет "жрать" адреса в процессе даже не занимая при этом физическую память (что будет ощущатся в 32 битных системах, а в 64-битных этим я думаю можно принебречь).
Мне кажется асинхронный вызов должен делатся только там, где он по логике асинхронный. Синхронный не в пример малозатратнее и главное проще - поэтому ядро L4 например работает только с синхронными вызовами. Но простота в этом случае оборачивается "попом" когда асинхронные вызовы нужны...
В общем самое лучшее это баланс...

Каждый слот вызывается не напрямую, а через обёртку. Поэтому ему не нужен отдельный стек. Все слоты работают с общем стеком. Асинхронность это не паралельность. Асинхронность это корпоративная многозадачность. Каждый слот привязан к сигналу. Слоты это просто функции лежащие в массиве и простой цикл вызывает все слоты по очереди. Тем самым они по переменно не мешая друг-другу работают с общим стеком. Однако сигнал можно соединить с сигналом. Получим дерево сигналов. Введя приоритеты можно управлять очерёдностью выполнения. Причём, даже можно чередовать слоты с разных веток.
Существует куча методов для защиты стека. К примеру отказаться от указателей. Seh-фрейм который стааит маркер 0xDEADBEFF. И прочии. Поэтому насчёт разрушение общего стека я не опасаюсь.