Только не говорите, что знали и часто пользуетесь!

В общем, тем, кому позарез нада получить сабж, оказалось все очень просто



Как объявили все volatile - компилятор все, включая входные параметры, кладет в стек-фрейм.

И логика проста: без соответствующих оптимизаций функции генерятся реентерабельными. Volatile как-раз и отключает эту оптимизацию локальных переменных.

В общем, в мануале ГЦЦ настолько туманно это описано, что побудило поделиться радостной новостью.

Продолжим нашу шизофрению. Как выяснилось, при размещении в стеке переменных достаточный размер переключаемого контекста AVR будет 6 байт! Это даже меньше, чем я на асме делал, протупил - получалось 8 байт.



Т.е. для организации точки входа сопрограммы используется косвенный goto, указатель стека текущей сопрограммы и указатель на локальные данные, который можно получить __builtin_frame_ptr(0). Ввиду того, что жесткого реалтайма не будет, на сохранение регистров в сопрограммах можно вообще не обращать внимание, в смысле - запретить. В общем, 6 байт - это намного меньше, чем в setjmp()

Что-то в этом есть. В отличие от указателем на структуру с данным процесса-сопрограммы, это даёт возможность переключаться не только в "корневой" функции, но и в любом месте по глубине вызовов. Но это уже приведёт к потере части преимущества по стеку (да, все регистры уже не сохраняются, но для каждого сопроцесса нужно всё равно резервировать свой стек достаточной глубины).
Правда, по сравнению с вытесняющмим системами, остаётся преимущество по времени синхронного переключения. А вот с асинхронным (из прерывания) - всё равно надо весь контекст сохранять, так как промежуточные вычисления на регистрах делаются, архитектура-то не стековая.

Хотя для этого органичнее стековая архитектура. О которой ругаются в теме про архитектуру контроллера.
На AVR такая модель не ложится, это на PDP-11 ещё можно было эмулировать - делать add 4(R3),8(R3) и только R3 да SP и сохранять (или вообще только SP для четырёх сопроцессов с базами в R0..R3, но они не смогли бы разделять между собой подпрограммы из-за разных баз), хотя, вероятно, выигрыш на переключении растерялся бы на проигрыше в эффектичности самих вычислений.

Что-то я недоспал и всё не соображу. И уже бегу.
Но интересно.

Если вызываемые процедуры построены также. На счет стека - се ля ви - сколько процессов, столько и стеков.

Вот этого и не понимаю - "за что боролись".
Стеки каждому свои.
На стеке место нужно под всю глубину вызовов.
Место под регистры на стеках не нужны только если все переключения задач синхронные.
Если могут быть асинхронные переключения (из прерываний), то на стеках нужно место под полное сохранение контекста, с регистрами, так как прерывание может произойти в промежуточных операциях до записи результата в переменную на стеке.

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

• вызовом функции шага каждого процесса do_XXX_step(), делающей небольшой кусок работы и сохраняющей рещультат в статичесокй структуре состояния процесса
  либо
  сопрограммными переключениями на верхнем уровне процесса, когда стек тоже в некотором смысле "очищен"
• вытесняющей ОС

Причем у "среднего" память расходуется почти как у второго, а всё остальное - практически как у первого.

Или я чего-то не понимаю по сонности своей в последние пару недель?

---------------------------

Где-то пробегал линк на систему над автоматами, в которой (если я правилно помню, тогда пробежался по диагонали) всё происходит синхронно, при каждом автомате набор стандартных функций - "обычный" "сделать кусок", и "обработчики прерываний высокого уровня". У планировщика очередь, где стоят указатели на функции для автоматов которые надо выполнить и таймерные переменные (функция запускается кода дотикает). Кажется ещё приоритеты при этих указателях.
В прерываниях делается самое быстрое типа сохранения байта UART в памяти и в очередь помещается указатель на соответствующий "обработчик высокого уровня" с флагом "как только, так сразу".
Ну а планировщик после синхронного возврата из очередной функции пробегается по очереди и решает, по какому указателю вызвать следующую. Которая тоже может поместить в очередь нечто, например, "сигнальную" функцию от другого автомата.
Всё чинно, синхронно, расход стека минимальный, никаких практически блокировок доступа к структурам не нужно, так как всё синхронно.
Всё это сделано горстью макросов и выглядит довольно красиво и читабельно.

Не уверен, что я правильно напел Битлз по телефону, но если кто-то таке встречал - дайте линк. А то у меня потерялся.

В общем, пока ясно одно: нельзя смешивать синхронное и асинхронное переключения.

Шорт побори, это было TinyTimber (Vit aka sensor_ua показал когда-то)
В прерываниях тоже всё работает - выходит, что обработчик прерывания сохраняет всё то, что не обязаны сохранять вызываемые подпрограммы, а планировщик в конце обработчика прерывания сохраняет через setjump остальное и по longjump переходт на другой процесс.
Когда на данный процесс переключатся опять по longjump - оно всплывёт уже непосредственно перед эпилогом обработчика прерывания с восстановленными callee-saved регистрами, эпилог восстановит caller-saved и SREG. Всё пучком.
Только в примере (по ссылке от Vit, эти исходники ненагугливаются по слову TinyTimber) сумма блока описания задачи (с буфером jumpbuf) и стека для задачи занимают где-то столько же, сколько и обычные стеки для AVR в scmRTOS, что вполне естественно.
Т.е. явных преимуществ по памяти нет, оно, как уже отмечалось, было бы при только синхонном переключении и только на верхних уровнях, в "корневых" функциях автоматов (тогда на всех один стек).

Если я правильно понял при беглом просмотре - преимущество просматривается в, фактически, диамическом создании/удалени задач, массивы описателей потоков и стеков - это массивы запущенных и выолняющегося плюс отложенных "методов", а не "процессов". Т.е. "спящий процесс" - это объект, у которого не запущен ни один "метод", т.е. никакой его код не работает, только сохраняется состояние автомата в его переменных, до которых ОС нет дела. А когда, например, "драйвер"-обработчик прерывания UART отошлёт весь пакет, тогда он из прерывания заланирует отработку соответствущего "метода" соответствующего "объекта" путём постановки "сообщения" в очередь. И он (метод) через сообщение привяжется к свободному блоку задачи/стеку, обработается через run() этого свободного "слота выполнения" (сразу или когда таковой освободится).

Очередь сообщений TinyTimber тоже где-то эквиваленна по памяти набору событий/мьютексов, будет или нет преимущство зя счёт динамического распределения - тяжело сказать. И беда может обнаружиться только во время выполнения, а в случае scmRTOS просто при компиляции не хватит памяти для всех заявленных объектов ОС.

Как-нибудь надо будет ещё покурить эту тему...

Еще одна ТАСКАЛКА (от слова task) получилась.
[attachment=36203:coos.zip]
Несколько слов

*param - для создания статических локальных переменных с учетом требований реентерабельности.
*entry - для использования переопределяемых точек входа с помощью гнусной фичи labels as values
В общем - мне пока понравилась такая мысль:
с одной стороны - через вызов system() можно отдавать управление другим задачам во время ожидания событий
с другой стороны, чтоб не мучать стек обратными вызовами, можно использовать переопределяемые точки входа и смело выходить из задачи, пока не наступит нужное нам событие.

Как Вам такой гибрид, уважаемый ReAl ?
PS к тому же system() можно спрятать внутри любой реентерабельной функции, а точки входа - низзя.
Теперь в TCB добавить поля для сообщений - и ось на подходе

Да, system() некоторые вещи сделает красивее, но при этом если несколько задач из списка позовут system() (да ещё и из функции - а иначе кайфу в вызове system() никакого по сравнению с просто установокй метки и возвратом) - стек как-то глубоко пойдёт, надо помнить о возможности.
В этом смысле вместо
"стандартный" protothread-овский
по стеку экономнее, так как ставит метку и даёт возврат из функции, а там уже просматривается список потоков.
Никто не мешает комбинировать.

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

А вообще Vit на protothread-подобных вещах стаю собак сожрал, это с ним обсуждать надо.

Никто и не заставляет всюду им пользоваться В тяжелых случаях перед вызовом должна быть проверка стека.

Не-не. Если есть ENTRY(), то можно обойтись без system()

ЗЫ: Да и что толку от его тотального использования - в залоченном состоянии задача не обработает ни одного нового события.



Отдельное спасибо за то, что напомнили про анонимные метки в PT_WAIT_UNTIL
Добавлю.
Но именные метки оставить надо, для возможного повторного использования точки входа.


Имхо, правильнее просто передавать указатель на локальные переменные из system(), вместо полного TCB. Тогда обращение к полям TCB будет доступно только через осевые сервисы.

Ага. И чтобы можно было пользоваться break /continue внутри ENTRY надо сделать

Ну и что в этом хорошего? Точнее, что хорошего в том, что эти сервисы вместо коротких inline-вызовов/макросов, обращающихся к полям TCB смещением к тому же указателю, который используеся для локальных переменных потока - вместо этого будут чем-то более толстым и медленным?

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

Все-таки есть смысл в первоначальной структуре заголовка, т.к void* param нуждается в типизации, которую и можно сделать при входе в функцию один раз. К тому же, задачи могут вообще не иметь локальных статических параметров.

Как всегда - выбор между примерно равноправными вариантами...

У каждой очереди есть свой персональный блок указателей/флагов - для любого построения системы.
А у двух одинаковых процессов локальные данные должны быть свои и указатели на локальные переменные не могут быть одинаковые.
Вот эти локальные переменные в TCB пусть и сидят.
А вот функция одна для обеих "писателей" и одна для обеих "читателей".

В этом случае для моего варианта в структуре TCB будет одно поле - заголовок.

Понял, спасибо. Но не сразу Если локальных параметров нету, то нах он нужен, этот param=NULL

Кстати, о protothread

parallel.h

Это есть самый минимальный набор для построения тредов.
Это самый обрезанный и самый простой protothread-подобный в мире

Решил скрестить прототредоподобную кооперативку и функцию system() или idle() или как там ея..
Я про блокировку рекурсивного вызова при использовании system() внутри треда . Получается вот что


Немного кривовато, но по-другому не получается. Пробовал по-всякому - оптимизирует, зараза, начисто.
А есть ли еще варианты блокировки без привлечения дополнительных переменных?
upd: состояние THREAD_LOCK наверное лучше обозначить как pc = <адрес функции-треда> чтобы не влазить куда не надо.