VLLV (11.06.2020 20:37, просмотров: 796) ответил fk0 на Прототреды это биг-луп вывернутый наизнанку. Или наоборот. То же
самое, что конечные автоматы им. Шалыто, switch-технология. Удобней
представлять в виде big loop всё-таки. Идея в том, что какой-то
"протопоток", "автомат", отдал управление обратно циклу и он
побежал вызывать остальные "протопотоки" или автоматы...-
- В состоянии ожидания он постоянно проверяет некоторую переменную.
Если переменных много, когда параллельных/независимых автоматов
много -- эти проверки оказываются чрезмерно длительными. Вложенные
КА (в терминологии switch-технологии Шалыто) отчасти спасают
ситуацию, но в целом проблема остаётся: сильно параллельные задачи
методом big loop, switch-технологие, с помощью protothreads --
эффективно не решаются. При том, что с ними элементарно справится
планировщик типовой RTOS. - fk0(11.06.2020 20:45)
- Вызов вложенных автоматов можно организовать с разной частотой,
соответсвующей необходимой скорости обработки. Это исключит тупую
проверку. Да, сильно параллельные ДОЛГОВРЕМЕННЫЕ задачи сложно
реализовать методом биглуп, но я за свою жизнь с этим столкнулся
только в одном проекте из десятков. А ресурсы нужно делить в каждом
втором. - VLLV(11.06.2020 21:27)
- Это уже пошли костыли и подпорки. Я хотел акцентировать внимание на
проблеме, что bigloop плохо масштабиуется. Он хорош пока маленький,
когда становится большой -- он еле ворочается. Как и прототреды,
как и switch-технология. По сути это всё одно и то же. Чтоб
ворочалось побыстрее нужен какой-то механизм, планировщик, который
будет знать кому какие события интересны и вызывать обработчик
события по факту его получения (а не опрашивать каждое событие в
цикле из обработчика fk0(37 знак., 11.06.2020 23:37)
- У события делать список задач, ожидающих события? И, вестимо, у них есть приоритеты. - Dingo(15.06.2020 17:38)
- Такой планировщик называется системой прерываний, и это прослойка есть и в биглупе и в ОС. - VLLV(12.06.2020 04:48)
- Это уже пошли костыли и подпорки. Я хотел акцентировать внимание на
проблеме, что bigloop плохо масштабиуется. Он хорош пока маленький,
когда становится большой -- он еле ворочается. Как и прототреды,
как и switch-технология. По сути это всё одно и то же. Чтоб
ворочалось побыстрее нужен какой-то механизм, планировщик, который
будет знать кому какие события интересны и вызывать обработчик
события по факту его получения (а не опрашивать каждое событие в
цикле из обработчика fk0(37 знак., 11.06.2020 23:37)
- А зачем, блядь он ее проверяет?! Пусть не проверяет, пусть выберет десяток,
случайным образом, будет быстро. Мужики, так нельзя. Если технически возможно аппаратное выявление изменения состояния входов автомата (АКА
прерывание), то это можно использовать, а если нет - можно только
то, что можно. Cкpипaч(222 знак., 11.06.2020 20:52)
- Со switch-технологией наверняка знаком? А что ему делать -- там
автомат следит за своими входами и, что более важно, может
изменение переменной состояния другого автомата воспринимать как
свой входной сигнал. Последнее принципиально важно, т.к. является
одним из способов коммуникации автоматов между собой (второй способ
работает только на передачу информации -- прямой вызов функции
автомата с передачей номера входного сигнала). И если у нас есть
множество параллельных fk0(968 знак., 11.06.2020 21:18)
- Организуйте очередь событий и отстаньте от совы. - Cкpипaч(11.06.2020 21:46)
- И получится Quantum Leap он же state-machine.com. И сразу будут
спрашивать, "а что если очередь событий переполнится". И ведь
переполняется бывает. С очередью есть одна принципиальная проблема:
события из очереди обрабатываются в порядке очереди. И если она
одна на всё, то возможен "шторм событий", когда некоторые события
попавшие на вход генерируют достаточно большое количество
внутренний событий, и так рекурсивно. И если на вход поступает
сразу много "проблемных" событий, fk0(815 знак., 11.06.2020 23:34)
- Стоп. Основная идея машины состояний - разделение входов, выходов и не-асинхронность. Иначе гонки можно и без очередей получить. Cкpипaч(1079 знак., 12.06.2020 10:12)
- И получится Quantum Leap он же state-machine.com. И сразу будут
спрашивать, "а что если очередь событий переполнится". И ведь
переполняется бывает. С очередью есть одна принципиальная проблема:
события из очереди обрабатываются в порядке очереди. И если она
одна на всё, то возможен "шторм событий", когда некоторые события
попавшие на вход генерируют достаточно большое количество
внутренний событий, и так рекурсивно. И если на вход поступает
сразу много "проблемных" событий, fk0(815 знак., 11.06.2020 23:34)
- Организуйте очередь событий и отстаньте от совы. - Cкpипaч(11.06.2020 21:46)
- Со switch-технологией наверняка знаком? А что ему делать -- там
автомат следит за своими входами и, что более важно, может
изменение переменной состояния другого автомата воспринимать как
свой входной сигнал. Последнее принципиально важно, т.к. является
одним из способов коммуникации автоматов между собой (второй способ
работает только на передачу информации -- прямой вызов функции
автомата с передачей номера входного сигнала). И если у нас есть
множество параллельных fk0(968 знак., 11.06.2020 21:18)
- Вызов вложенных автоматов можно организовать с разной частотой,
соответсвующей необходимой скорости обработки. Это исключит тупую
проверку. Да, сильно параллельные ДОЛГОВРЕМЕННЫЕ задачи сложно
реализовать методом биглуп, но я за свою жизнь с этим столкнулся
только в одном проекте из десятков. А ресурсы нужно делить в каждом
втором. - VLLV(11.06.2020 21:27)
- В состоянии ожидания он постоянно проверяет некоторую переменную.
Если переменных много, когда параллельных/независимых автоматов
много -- эти проверки оказываются чрезмерно длительными. Вложенные
КА (в терминологии switch-технологии Шалыто) отчасти спасают
ситуацию, но в целом проблема остаётся: сильно параллельные задачи
методом big loop, switch-технологие, с помощью protothreads --
эффективно не решаются. При том, что с ними элементарно справится
планировщик типовой RTOS. - fk0(11.06.2020 20:45)