Я задал конкретный технический вопрос о критериях параллельной программы. Вместо ответа по существу Вы оскорбили меня и неизвестных мне студентов.
Это говорит о том, что конструктивный диалог с вами невозможен. Терминологические споры — это нормально. Переход на личности — нет.
Моя работа и её качество — предмет оценки сообщества и моих заказчиков, а не ваших личных выпадов. На этом наш текущий диалог я считаю исчерпанным. Учтите это, если желаете общаться со мной и дальше.
А вот, если у кого-то есть конкретные технические вопросы по существу статьи или библиотеки — я всегда рад продуктивному обсуждению.
Спасибо за интересный комментарий! Вы правы и попали в самую суть. То, что вы описываете — это классическая кооперативная многозадачность (cooperative multitasking). Не пробовал, но, думаю, он отлично сработает.
Если разбить всю программу на шаги и переключать контекст только вручную в точках блокировки, мы получим детерминированную систему. Фактически, каждый такой блокирующий вызов (вроде delay(), await, yield) — это и есть неявное состояние конечного автомата.
Тогда в чём же разница? Мой подход — это эволюция этой идеи, которая решает несколько практических проблем чистого кооперативного подхода:
Проблема масштабирования и читаемости. Когда у вас 10-20-100 задач, ручное управление точками yield превращается в спагетти-код, где состояние системы распределено по всем функциям и скрыто в порядке вызовов. Автомат делает это состояние явным и централизованным. Вместо того чтобы гадать, в каком месте какая функция остановилась, вы контролируете состояние автомата.
Проблема ремонтопригодности и ошибок. Добавить новое состояние или событие в ручной код с yield очень сложно — можно сломать всю логику. В автомате это делается добавлением одной строки в таблицу переходов. Это делает код модульным и защищённым от ошибок.
Проблема формальной верификации. Автомат, заданный таблицей переходов, можно формально проверить на недостижимые состояния, deadlock'и и т.д. Сделать это с кодом, перемешанным с yield, практически невозможно.
Проще говоря, ваш подход — это то, как это работает под капотом. А автомат — это инструмент проектирования, который позволяет управлять этой сложностью на высоком уровне, не задумываясь каждый раз о ручной расстановке точек останова.
Вы же не изобретаете автомат — вы неосознанно его реализуете. Моя библиотека просто предлагает делать это явно, системно и с меньшими затратами на поддержку.
Спасибо, что подняли этот вопрос! Вы прекрасно проиллюстрировали, что проблема действительно актуальна, и её можно решать разными способами на разных уровнях абстракции.
Когда пытаются размазывать или припирать, то нормальная реакция - дать адекватный ответ. И тут начинается - от "а ты кто такой" до "а нас то за что?"... Но не будем сразу "хвать за грудки" друг друга. Это не наш подход, т.к. мы, надеюсь, адекватные ребята.
Но дело совсем не в этом. Мне понравилась Ваша ассоциация с "поляной". И тут как бы мы не хотели, о чем бы не мечтали, но ... поляна у нас одна - параллельное программирование и хочешь не хочешь, а ее как-то надо делить. Но есть и другие варианты - занять ее полностью, выдавив конкурента, или ретироваться, понимая, что здесь ловить нечего. Я за мирное разрешения проблемы и постоянно об этом говорю.
Может я ошибаюсь, но вы напоминаете мне охранника, которому дали указание - не пущать! и он должен этот приказ выполнять. С охранником договариваться смысла нет и я, очень надеюсь, что это не этот случай.
Но тогда явно должен быть "адекватный начальник", отдавший указание, но с которым можно договориться. Все же мы "одной крови" - параллельной и в такой ситуации можно и даже нужно договариваться. Иначе, действительно, .- кроме войны варианта не просматривается. Это надо тоже осознавать. "Охранник" явно не тот, с которым можно на эту тему разговаривать.
Но мне хотелось бы понять с кем я говорю - с "охранником" или "начальником"? А потому у меня к Вам вопрос: "Какую программу мы будем считать параллельной?"
Дайте ответ и я, возможно, пойму с кем разговариваю. Ведь, явно только правильный ответ на "пароль" - "параллельная программа" даст пропуск на упомянутую Вами "поляну", которую, так уж случилось, сейчас вы занимаете.
Вы задали хороший вопрос и в чем-то даже правы: да, эта библиотека и статья не про использование нескольких ядер CPU для ускорения вычислений. Если стоит задача распараллелить рендеринг видео, тренировку нейросети или обработку больших данных, то это совершенно не тот "молоток".
Но я о другом - об детерминированном управлении в embedded-системах и IoT. И вот почему библиотека VCPa - это не про «отсечение головы», а «точная хирургия»:
Из статьи должно быть ясно, что параллелизм != многопоточность на многоядерных CPU
В мире микроконтроллеров (ESP32, STM32, AVR) под «параллелизмом» чаще понимают конкурентное выполнение множества задач на одном ядре (concurrency), а не истинный параллелизм (parallelism). Проблема не в том, чтобы считать быстрее, а в том, чтобы управлять сотней независимых процессов (датчики, сеть, кнопки, дисплей) детерминированно и без гонок.
Цель: Надёжность, а не производительность
Для многих устройств (медицина, промышленная автоматика, умный дом) предсказуемость и отсутствие ошибок в 1000 раз важнее, чем использование всех ядер.
Потоки/Мьютексы на MCU — это сложно, рискованно и resource-heavy. Один deadlock — и устройство умрет и это на производстве.
Корутины - чуть лучше, но требуют ручного управления и скрывают состояние системы.
Автоматы — дают абсолютно детерминированную, проверяемую и визуализируемую модель. Мы жертвуем «истинным параллелизмом» ради гарантированной надёжности.
Нишевое применение — это сила
Да, этот подход не для всех. Он идеален для:
Управляющей логики: Протоколы связи, сами конечные автоматы бизнес-логики, обработка пользовательского ввода.
Систем, где ваша голова стоит дороже лишнего ядра: Медицинские приборы, промышленные контроллеры, бортовые системы.
Любого устройства, где есть жёсткие требования по времени отклика (не путать с вычислительной мощностью). Автомат гарантирует, что критическая реакция на событие всегда уложится в заданный timeout.
Короче: я предлагаю не «отказаться от параллелизма», а «решить проблему параллелизма другим, более подходящим для embedded-мира способом».
Спасибо, что дали возможность прояснить этот фундаментальный момент. Надеюсь, теперь контекст статьи стал понятнее.
Хотя я немного "дал в штангу" :) Если буквально понимать Ваш вопрос, то - всегда. Как так? Для этого нужно для параллельного алгоритма найти эквивалентный ему последовательный алгоритм. Вот это можно сделать всегда. Правда, это может потребовать уйму вычислений, но ... кто ж их формально считает? :) Главное, что такая возможность есть всегда.
Так что прошу прощения - просто я посмотрел на ваш вопрос в спешке слишком "в лоб" ;).
Всегда - нет. Конечно, все зависит от вида параллельного алгоритма, но если между параллельными потоками есть, так называемые, обратные связи (иногда их называют алгебраическими цепями, петлями), то точно нет.
Это мнение ИИ. У меня другое. Все же есть алгоритмы последовательные и параллельные. Так что параллелизм - это все же свойство алгоритма. Это следует также из выяснения какую же программу считать параллельной.
И тут сразу станет ясно, что на диаграмме изображена только вершина айсберга.А на Муре пришлось бы весь айсберг рисовать. Т.е. заниматься сизифовым трудом.
Я попросил нарисовать автомат, эквивалентный диаграмме. И тут я что-то не понял. Это так или нет? Если так, то я показал, как можно реализовать автомат Мура, а соответственно и диаграмму. Так? Далее. Упомянутое условие не "расшифровано" на диаграмме. Таким же оно будет и у автомата. Просто потому, что и автомат и диаграмма - это разные формы одного - описания логики работы объекта. Т.е. условия и действия, что у диаграммы, что у автомата должны быть одними и теми же. Так или нет? Так где тут "сизифов труд"? В реализации логики работы объекта? Или в реализации того, что скрыто за надписями на диаграмме.?
Понятней, конечно, автомат Мура. Он у Вас ближе к классической форме. А потому с ним все ясно. Имея такой автомат, мне нужно буквально минуты, что создать таблицу переходов (ТП). Вы условия и действия поставили на дуги, что загромождает автомат. Лучше сделать, как у меня. На графе написать условные сигналы (как я просил), а в сторонке их расшифровать. Они у Вас на вид совсем простые и их реализовать будет просто. На все про все, чтобы создать соответствующий автоматный класс в VCPa потребуется ну минут 30 максимум. Да пусть даже час потрачу. Но зато потом все будет под полным контролем. Что-то не получается у меня 800 строк. Выходит где-то строк 20-25 кода ТП и по одной две строки на каждый предикат и действие. Поскольку автомат Мура, то действий будет по числу состояний (10, а может даже меньше). Пусть каждый переход нагружен своим предикатом. Значит предикатов - по числу дуг. Ну, на вскидку получается строк 100. Никак не выходит 800. Согласны?
Да, чуть не забыл. Еще у Вас есть задержки. На каждую задержку тоже по действию (по числу разных задержек). Соответственно по одной строчке кода.
Но написать такую диаграмму в примением вашей "библиотеки" я бы даже не пытался
А давайте попробуем ;) Но только с Вашей помощью. Представьте диаграмму в форме классического автоматного графа (см. граф в статье). Только, оставив, вершины графа (состояния), упростить граф, нагрузив граф условными входными (x1, x2 ... и т.д.) сигналами и выходными (y1, y2 и т.д.). И для начала убрать иерархию состояний, представив вложенные состояния тоже автоматами. Лучше их также нарисовать отдельно (потом разберемся, как их связать с верхним уровнем иерархии). Ну, как - попытаемся?
А Ваш автомат на мой взгляд довольно простой. Это если оценивать граф. Его просто представить в рамках VCPa. В форме сети автоматов. В VCPa он/они будут в форме таблиц переходов. Может потребуется несколько автоматов, похоже будут вложенные автоматы, но в целом выглядит не таким уж сложным.
Проблема с предикатами и действиями. Их "начинку" по "рисунку" сложно представить. Они могут быть и очень простыми и очень сложными. Чтобы определиться нужно знать о чем идет речь.
А более эффективного способа, чем форма автоматов в VCPa мне не известна. Сеть на базе автоматов имеющих вложения опишет что угодно и достаточно компактно. А я уж, поверьте, повидал много и разных автоматов. От классических, до типа Харелла, UML и т.п.
Я просто предложил DeepSeek два комментария. Вот его итог:
Итог: Оба проанализированных комментария попадают в категорию наименее адекватных, просто демонстрируют разные виды токсичности: первый — прямолинейную агрессию, второй — высокомерное отрицание.
Какое такое "каскадирование"? Охренеть до чего можно додуматься!
Вопрос на смекалку. Вы подходите к "черному ящику", как Вы определите параллельный он или нет? Ну, ответьте. Ну, напрягите свой (без обид) мозжечок. Как отличить параллельную систему от квазипараллельной, если Вам не дают заглянуть в ее нутро? Ну, как?
Нет, ну как тут не возмущаться? "Примитивная реализация", понимаешь? У меня почти любой файл в два раза больше "мощной реализации" ChatGPT. Как Вы оцениваете мощь? По каким критериям? Ну, да ладно. Все гениальное простое, как сапог... Поэтому вернемся к нашим "мощам"...
Итак, - задержка. Где Вы увидели другой поток. Ну, прогуляйтесь до моей статьи там про нее все расписано. Это вложенный автомат. Извиняйте, что не расписываю детали. Извиняйте, что ссылаюсь опять на свои статьи. Это надо же статью пересказать! Не проще ли прочитать, а?
Итак, в VCPa поток - это автомат. Задержка - это вложенный автомат, вызываемый автоматам. Аналог подпрограммы. А, кстати, вложенные потоки есть?
Далее. Разница между моей "операционкой" и ChatGPT в том, что она реализует АЛГОРИТМИЧЕСКУЮ МОДЕЛЬ!!! Последняя - только создает, видимо, некие потоки. Может, корутины. Короче - все что было, то и осталось. Вот, истинно "полная мутабельность". И Вы еще утверждаете, что она мощнее? Грустно все это. Народ не любит читать, народ не любит вникать. Может, конечно, элементарно нет на это время? Но время надо находить на чтение. Это должно быть частью профессии. Ну, как иначе, ребята? Так вы никогда не разберетесь в том, что даже обсуждаете. И во всем нужно искать основу, причины. Без этого не будет решений. Так и будем бороться с "мутабельностью" (красивое, блин, слово!) до скончания веков.
Но если критикуете, то хотя бы нужно понимать что, где и как. А то - мощнее и все!? "Вигвам", как говаривал кто-то, может, кот Матроскин.
Можно я с Вашего разрешения процитирую себя самого:
Но обязательно найдется тот, кто‑то возразит по поводу однопоточного параллелизма. Но в этом нет ничего необычного, т. к. вопрос параллелизма целиком лежит во власти модели вычислений, а не ее реализации. Если модель параллельна и корректно реализована, то параллельны будут и представленные ею процессы. Таков простой и краткий ответ, рассеивающий подобные сомнения.
Вы и есть "тот" ;) Вот только не знаю поймете ли Вы о чем здесь идет речь. "Квазипараллелизм" он в современных потоках, корутинах, многоядерных системах и т.д. (перечисляете, что хотите). В той или иной мере их можно использовать или попытаться использовать для реализации реального параллелизма. Но с разной степенью успеха. Например, на потоках мне не удалось создать ядро, хотя потоки я попробовал пристегнуть к модели и что-то даже получилось. Их "мутабельность" мне побороть не удалось :)
Но все же. Вы программируете в рамках модели и как она реализована, что у ней под капотом по большому счету не должно интересовать программиста. Только, если он сильно любопытный. Вот как Вы сейчас, пытаясь выяснить, как реализовано ядро и есть ли в нем потоки. Я уже сказал - нет. В реализации ядра - нет. На уровне модели есть. Есть вариант с их использованием. API библиотеки это отражает.
Он не все может, видимо, идентифицировать. Понять, какую алгоритмическую модель реализуют процессы библиотеки он, похоже, не может. А посему библиотеки, реализующие параллельную автоматную модель программирования мне неизвестны. Ни новых, ни, тем более, старых. Если что-то пропустил, то подскажите. Буду весьма благодарен ;)
Что заставило взяться за старое?
Для меня это не "старое", а то настоящие, что я использую, заменяя "старые-новые" потоки и корутины. Права, иногда экспериментирую с потоками (что, кстати, отражает API), но очень-очень редко.
...а оно поменялось на другое еще до того, как мы из операции чтения вышли.
Чтобы такого не было в принципе процессы должны функционировать в рамках модели параллельных вычислений (как бы это не было кому-то противно). В противном случае мы будем иметь описанный "кошмар". "Кошмар мутабельности". И, что печально, он существует на самом деле! Не поможет даже FreeRTOS, т.к. она базируется на многопоточности. Т.е. мутабельность заложена в идеологию. Используйте VCPa и с подобным вы никогда не столкнетесь.
И о состояниях. Они не разделяемый ресурс. Да их читать может кто угодно, но изменять - только сам автомат. Но это, конечно, чистая теория. В VCPa есть возможность изменять состояние автомата извне, но злоупотреблять подобными фишками нужно осторожно.
А не сложно его повторить, чтобы все с ним ознакомились еще раз?
Я задал конкретный технический вопрос о критериях параллельной программы. Вместо ответа по существу Вы оскорбили меня и неизвестных мне студентов.
Это говорит о том, что конструктивный диалог с вами невозможен. Терминологические споры — это нормально. Переход на личности — нет.
Моя работа и её качество — предмет оценки сообщества и моих заказчиков, а не ваших личных выпадов. На этом наш текущий диалог я считаю исчерпанным. Учтите это, если желаете общаться со мной и дальше.
А вот, если у кого-то есть конкретные технические вопросы по существу статьи или библиотеки — я всегда рад продуктивному обсуждению.
Спасибо за интересный комментарий! Вы правы и попали в самую суть. То, что вы описываете — это классическая кооперативная многозадачность (cooperative multitasking). Не пробовал, но, думаю, он отлично сработает.
Если разбить всю программу на шаги и переключать контекст только вручную в точках блокировки, мы получим детерминированную систему. Фактически, каждый такой блокирующий вызов (вроде
delay(),await,yield) — это и есть неявное состояние конечного автомата.Тогда в чём же разница? Мой подход — это эволюция этой идеи, которая решает несколько практических проблем чистого кооперативного подхода:
Проблема масштабирования и читаемости. Когда у вас 10-20-100 задач, ручное управление точками
yieldпревращается в спагетти-код, где состояние системы распределено по всем функциям и скрыто в порядке вызовов. Автомат делает это состояние явным и централизованным. Вместо того чтобы гадать, в каком месте какая функция остановилась, вы контролируете состояние автомата.Проблема ремонтопригодности и ошибок. Добавить новое состояние или событие в ручной код с
yieldочень сложно — можно сломать всю логику. В автомате это делается добавлением одной строки в таблицу переходов. Это делает код модульным и защищённым от ошибок.Проблема формальной верификации. Автомат, заданный таблицей переходов, можно формально проверить на недостижимые состояния, deadlock'и и т.д. Сделать это с кодом, перемешанным с
yield, практически невозможно.Проще говоря, ваш подход — это то, как это работает под капотом. А автомат — это инструмент проектирования, который позволяет управлять этой сложностью на высоком уровне, не задумываясь каждый раз о ручной расстановке точек останова.
Вы же не изобретаете автомат — вы неосознанно его реализуете. Моя библиотека просто предлагает делать это явно, системно и с меньшими затратами на поддержку.
Спасибо, что подняли этот вопрос! Вы прекрасно проиллюстрировали, что проблема действительно актуальна, и её можно решать разными способами на разных уровнях абстракции.
Когда пытаются размазывать или припирать, то нормальная реакция - дать адекватный ответ. И тут начинается - от "а ты кто такой" до "а нас то за что?"... Но не будем сразу "хвать за грудки" друг друга. Это не наш подход, т.к. мы, надеюсь, адекватные ребята.
Но дело совсем не в этом. Мне понравилась Ваша ассоциация с "поляной". И тут как бы мы не хотели, о чем бы не мечтали, но ... поляна у нас одна - параллельное программирование и хочешь не хочешь, а ее как-то надо делить. Но есть и другие варианты - занять ее полностью, выдавив конкурента, или ретироваться, понимая, что здесь ловить нечего. Я за мирное разрешения проблемы и постоянно об этом говорю.
Может я ошибаюсь, но вы напоминаете мне охранника, которому дали указание - не пущать! и он должен этот приказ выполнять. С охранником договариваться смысла нет и я, очень надеюсь, что это не этот случай.
Но тогда явно должен быть "адекватный начальник", отдавший указание, но с которым можно договориться. Все же мы "одной крови" - параллельной и в такой ситуации можно и даже нужно договариваться. Иначе, действительно, .- кроме войны варианта не просматривается. Это надо тоже осознавать. "Охранник" явно не тот, с которым можно на эту тему разговаривать.
Но мне хотелось бы понять с кем я говорю - с "охранником" или "начальником"? А потому у меня к Вам вопрос: "Какую программу мы будем считать параллельной?"
Дайте ответ и я, возможно, пойму с кем разговариваю. Ведь, явно только правильный ответ на "пароль" - "параллельная программа" даст пропуск на упомянутую Вами "поляну", которую, так уж случилось, сейчас вы занимаете.
Разве не так?
Вы задали хороший вопрос и в чем-то даже правы: да, эта библиотека и статья не про использование нескольких ядер CPU для ускорения вычислений. Если стоит задача распараллелить рендеринг видео, тренировку нейросети или обработку больших данных, то это совершенно не тот "молоток".
Но я о другом - об детерминированном управлении в embedded-системах и IoT. И вот почему библиотека VCPa - это не про «отсечение головы», а «точная хирургия»:
Из статьи должно быть ясно, что параллелизм != многопоточность на многоядерных CPU
В мире микроконтроллеров (ESP32, STM32, AVR) под «параллелизмом» чаще понимают конкурентное выполнение множества задач на одном ядре (concurrency), а не истинный параллелизм (parallelism). Проблема не в том, чтобы считать быстрее, а в том, чтобы управлять сотней независимых процессов (датчики, сеть, кнопки, дисплей) детерминированно и без гонок.
Цель: Надёжность, а не производительность
Для многих устройств (медицина, промышленная автоматика, умный дом) предсказуемость и отсутствие ошибок в 1000 раз важнее, чем использование всех ядер.
Потоки/Мьютексы на MCU — это сложно, рискованно и resource-heavy. Один deadlock — и устройство умрет и это на производстве.
Корутины - чуть лучше, но требуют ручного управления и скрывают состояние системы.
Автоматы — дают абсолютно детерминированную, проверяемую и визуализируемую модель. Мы жертвуем «истинным параллелизмом» ради гарантированной надёжности.
Нишевое применение — это сила
Да, этот подход не для всех. Он идеален для:
Управляющей логики: Протоколы связи, сами конечные автоматы бизнес-логики, обработка пользовательского ввода.
Систем, где ваша голова стоит дороже лишнего ядра: Медицинские приборы, промышленные контроллеры, бортовые системы.
Любого устройства, где есть жёсткие требования по времени отклика (не путать с вычислительной мощностью). Автомат гарантирует, что критическая реакция на событие всегда уложится в заданный timeout.
Короче: я предлагаю не «отказаться от параллелизма», а «решить проблему параллелизма другим, более подходящим для embedded-мира способом».
Спасибо, что дали возможность прояснить этот фундаментальный момент. Надеюсь, теперь контекст статьи стал понятнее.
Хотя я немного "дал в штангу" :) Если буквально понимать Ваш вопрос, то - всегда. Как так? Для этого нужно для параллельного алгоритма найти эквивалентный ему последовательный алгоритм. Вот это можно сделать всегда. Правда, это может потребовать уйму вычислений, но ... кто ж их формально считает? :) Главное, что такая возможность есть всегда.
Так что прошу прощения - просто я посмотрел на ваш вопрос в спешке слишком "в лоб" ;).
Всегда - нет. Конечно, все зависит от вида параллельного алгоритма, но если между параллельными потоками есть, так называемые, обратные связи (иногда их называют алгебраическими цепями, петлями), то точно нет.
Это мнение ИИ. У меня другое. Все же есть алгоритмы последовательные и параллельные. Так что параллелизм - это все же свойство алгоритма. Это следует также из выяснения какую же программу считать параллельной.
Я попросил нарисовать автомат, эквивалентный диаграмме. И тут я что-то не понял. Это так или нет? Если так, то я показал, как можно реализовать автомат Мура, а соответственно и диаграмму. Так? Далее. Упомянутое условие не "расшифровано" на диаграмме. Таким же оно будет и у автомата. Просто потому, что и автомат и диаграмма - это разные формы одного - описания логики работы объекта. Т.е. условия и действия, что у диаграммы, что у автомата должны быть одними и теми же. Так или нет? Так где тут "сизифов труд"? В реализации логики работы объекта? Или в реализации того, что скрыто за надписями на диаграмме.?
Понятней, конечно, автомат Мура. Он у Вас ближе к классической форме. А потому с ним все ясно. Имея такой автомат, мне нужно буквально минуты, что создать таблицу переходов (ТП). Вы условия и действия поставили на дуги, что загромождает автомат. Лучше сделать, как у меня. На графе написать условные сигналы (как я просил), а в сторонке их расшифровать. Они у Вас на вид совсем простые и их реализовать будет просто. На все про все, чтобы создать соответствующий автоматный класс в VCPa потребуется ну минут 30 максимум. Да пусть даже час потрачу. Но зато потом все будет под полным контролем. Что-то не получается у меня 800 строк. Выходит где-то строк 20-25 кода ТП и по одной две строки на каждый предикат и действие. Поскольку автомат Мура, то действий будет по числу состояний (10, а может даже меньше). Пусть каждый переход нагружен своим предикатом. Значит предикатов - по числу дуг. Ну, на вскидку получается строк 100. Никак не выходит 800. Согласны?
Да, чуть не забыл. Еще у Вас есть задержки. На каждую задержку тоже по действию (по числу разных задержек). Соответственно по одной строчке кода.
А давайте попробуем ;) Но только с Вашей помощью. Представьте диаграмму в форме классического автоматного графа (см. граф в статье). Только, оставив, вершины графа (состояния), упростить граф, нагрузив граф условными входными (x1, x2 ... и т.д.) сигналами и выходными (y1, y2 и т.д.). И для начала убрать иерархию состояний, представив вложенные состояния тоже автоматами. Лучше их также нарисовать отдельно (потом разберемся, как их связать с верхним уровнем иерархии). Ну, как - попытаемся?
Это не я - это DeepSeek ;).
А Ваш автомат на мой взгляд довольно простой. Это если оценивать граф. Его просто представить в рамках VCPa. В форме сети автоматов. В VCPa он/они будут в форме таблиц переходов. Может потребуется несколько автоматов, похоже будут вложенные автоматы, но в целом выглядит не таким уж сложным.
Проблема с предикатами и действиями. Их "начинку" по "рисунку" сложно представить. Они могут быть и очень простыми и очень сложными. Чтобы определиться нужно знать о чем идет речь.
А более эффективного способа, чем форма автоматов в VCPa мне не известна. Сеть на базе автоматов имеющих вложения опишет что угодно и достаточно компактно. А я уж, поверьте, повидал много и разных автоматов. От классических, до типа Харелла, UML и т.п.
Спасибо за замечание. Есть там теперь такая папка и в ней даже рассмотренный пример ;)
Я просто предложил DeepSeek два комментария. Вот его итог:
Какое такое "каскадирование"? Охренеть до чего можно додуматься!
Вопрос на смекалку. Вы подходите к "черному ящику", как Вы определите параллельный он или нет? Ну, ответьте. Ну, напрягите свой (без обид) мозжечок. Как отличить параллельную систему от квазипараллельной, если Вам не дают заглянуть в ее нутро? Ну, как?
Нет, ну как тут не возмущаться? "Примитивная реализация", понимаешь? У меня почти любой файл в два раза больше "мощной реализации" ChatGPT. Как Вы оцениваете мощь? По каким критериям? Ну, да ладно. Все гениальное простое, как сапог... Поэтому вернемся к нашим "мощам"...
Итак, - задержка. Где Вы увидели другой поток. Ну, прогуляйтесь до моей статьи там про нее все расписано. Это вложенный автомат. Извиняйте, что не расписываю детали. Извиняйте, что ссылаюсь опять на свои статьи. Это надо же статью пересказать! Не проще ли прочитать, а?
Итак, в VCPa поток - это автомат. Задержка - это вложенный автомат, вызываемый автоматам. Аналог подпрограммы. А, кстати, вложенные потоки есть?
Далее. Разница между моей "операционкой" и ChatGPT в том, что она реализует АЛГОРИТМИЧЕСКУЮ МОДЕЛЬ!!! Последняя - только создает, видимо, некие потоки. Может, корутины. Короче - все что было, то и осталось. Вот, истинно "полная мутабельность". И Вы еще утверждаете, что она мощнее? Грустно все это. Народ не любит читать, народ не любит вникать. Может, конечно, элементарно нет на это время? Но время надо находить на чтение. Это должно быть частью профессии. Ну, как иначе, ребята? Так вы никогда не разберетесь в том, что даже обсуждаете. И во всем нужно искать основу, причины. Без этого не будет решений. Так и будем бороться с "мутабельностью" (красивое, блин, слово!) до скончания веков.
Но если критикуете, то хотя бы нужно понимать что, где и как. А то - мощнее и все!? "Вигвам", как говаривал кто-то, может, кот Матроскин.
Можно я с Вашего разрешения процитирую себя самого:
Вы и есть "тот" ;) Вот только не знаю поймете ли Вы о чем здесь идет речь. "Квазипараллелизм" он в современных потоках, корутинах, многоядерных системах и т.д. (перечисляете, что хотите). В той или иной мере их можно использовать или попытаться использовать для реализации реального параллелизма. Но с разной степенью успеха. Например, на потоках мне не удалось создать ядро, хотя потоки я попробовал пристегнуть к модели и что-то даже получилось. Их "мутабельность" мне побороть не удалось :)
Но все же. Вы программируете в рамках модели и как она реализована, что у ней под капотом по большому счету не должно интересовать программиста. Только, если он сильно любопытный. Вот как Вы сейчас, пытаясь выяснить, как реализовано ядро и есть ли в нем потоки. Я уже сказал - нет. В реализации ядра - нет. На уровне модели есть. Есть вариант с их использованием. API библиотеки это отражает.
Он не все может, видимо, идентифицировать. Понять, какую алгоритмическую модель реализуют процессы библиотеки он, похоже, не может. А посему библиотеки, реализующие параллельную автоматную модель программирования мне неизвестны. Ни новых, ни, тем более, старых. Если что-то пропустил, то подскажите. Буду весьма благодарен ;)
Для меня это не "старое", а то настоящие, что я использую, заменяя "старые-новые" потоки и корутины. Права, иногда экспериментирую с потоками (что, кстати, отражает API), но очень-очень редко.
Не правильно понимаете. VCPa реализует модель программирования, которая подобные "кошмары" не допускает.
Чтобы такого не было в принципе процессы должны функционировать в рамках модели параллельных вычислений (как бы это не было кому-то противно). В противном случае мы будем иметь описанный "кошмар". "Кошмар мутабельности". И, что печально, он существует на самом деле! Не поможет даже FreeRTOS, т.к. она базируется на многопоточности. Т.е. мутабельность заложена в идеологию. Используйте VCPa и с подобным вы никогда не столкнетесь.
И о состояниях. Они не разделяемый ресурс. Да их читать может кто угодно, но изменять - только сам автомат. Но это, конечно, чистая теория. В VCPa есть возможность изменять состояние автомата извне, но злоупотреблять подобными фишками нужно осторожно.