C шаблон проектирования, выполняющий список действий без блокировки? - PullRequest
2 голосов
/ 08 февраля 2020

Встроенный C. У меня есть список того, что я хочу сделать, процедурно, в основном действия READ, WRITE и MODIFY, основываясь на результатах последнего утверждения. Каждое из них может занимать до 2 секунд, я не могу заблокировать.

Каждое действие может иметь состояния ЗАВЕРШЕНО и ОШИБКА, в которых есть подсостояния по причине возникновения ошибки. Или во время соревнования я захочу проверить или изменить некоторые данные.

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

Довольно просто, но я обнаружил, что для того, чтобы не блокировать, я трачу кучу усилий на постоянную проверку состояний, ошибок и краев. Снова и снова.

Я бы сказал, что 80% моего кода - это просто проверки и продвижение системы. Должен быть лучший способ!

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

Редактировать: я знаю, как использовать обратные вызовы, но на самом деле не вижу в этом «решения», поскольку мне просто нужно вернуться к другой части того же списка, чтобы сделать следующее. Может быть, было бы полезно знать бэкэнд о том, как работают asyn c и await на других языках?

Edit2: у меня есть ОСРВ для других проектов, но этот конкретный вопрос c, не предполагает никаких потоков / задачи, просто голый металл su perloop.

1 Ответ

2 голосов
/ 08 февраля 2020

Ваше затруднительное положение идеально подходит для конечных автоматов (на самом деле, вероятно, UML-диаграммы состояний ). Каждый отдельный запрос может обрабатываться на своем собственном конечном компьютере, который обрабатывает события (такие как COMPLETE или ERROR ) неблокирующим способом выполнения до завершения. По мере поступления событий конечный автомат запроса перемещается через различные состояния к завершению.

Для встроенных систем я часто использую управляемую событиями структуру QP для таких случаев. Фактически, когда я посмотрел эту ссылку, я заметил, что в самом первом абзаце используется термин «неблокирующая». Фреймворк предоставляет гораздо больше, чем конечные автоматы с иерархией (состояния внутри состояний), которая уже очень мощна.

На сайте также есть полезная информация о подходах к вашей конкретной проблеме c. Я бы предложил начать со страницы Key Concepts сайта.

Чтобы получить представление о содержании и его значимости для вашей ситуации:

Несмотря на Основываясь на фундаментальной управляемой событиями природе, большинство встроенных систем традиционно программируются последовательным образом, где программа жестко кодирует ожидаемую последовательность событий, ожидая определенных событий в различных местах пути выполнения. Это явное ожидание событий реализуется с помощью опроса занятости или блокировки по временной задержке и т. Д. c.

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

По этой и другим причинам эксперты по параллельному программированию научились быть очень осторожными с различными механизмами блокировки ОСРВ, потому что они часто приводят к программам, которые не отвечают, трудно рассуждать и небезопасны. Вместо этого эксперты рекомендуют [...] программирование на основе событий.

Вы также можете создавать конечные автоматы самостоятельно, не используя управляемую событиями среду, такую ​​как QP, но в итоге вы заново изобретете колесо ИМО.

...