|
Про реентерабельность, малоизвестная фича GCC |
|
|
|
Feb 15 2009, 23:51
|
;
     
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509

|
Только не говорите, что знали и часто пользуетесь!  В общем, тем, кому позарез нада получить сабж, оказалось все очень просто Код void somefunc (volatile int param) { volatile int local1; volatile char local2; //body local1 |= param; return; } Как объявили все volatile - компилятор все, включая входные параметры, кладет в стек-фрейм. И логика проста: без соответствующих оптимизаций функции генерятся реентерабельными. Volatile как-раз и отключает эту оптимизацию локальных переменных. В общем, в мануале ГЦЦ настолько туманно это описано, что побудило поделиться радостной новостью.
|
|
|
|
2 страниц
< 1 2
|
 |
Ответов
(15 - 29)
|
Feb 16 2009, 23:30
|
;
     
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509

|
Цитата(Rst7 @ Feb 16 2009, 12:26)  Тут _Pasha имеет в виду не классическое понятие реетерабельности как работу функции в многопоточном приложении, а как некий костыль, позволяющий организовать многопоточность с минимумом затрат памяти. Продолжим нашу шизофрению. Как выяснилось, при размещении в стеке переменных достаточный размер переключаемого контекста AVR будет 6 байт! Это даже меньше, чем я на асме делал, протупил - получалось 8 байт. Код typedef struct
{
uint16_t pc,sp,framePTR;
} small_ctx_t; Т.е. для организации точки входа сопрограммы используется косвенный goto, указатель стека текущей сопрограммы и указатель на локальные данные, который можно получить __builtin_frame_ptr(0). Ввиду того, что жесткого реалтайма не будет, на сохранение регистров в сопрограммах можно вообще не обращать внимание, в смысле - запретить. В общем, 6 байт - это намного меньше, чем в setjmp()
|
|
|
|
|
Feb 17 2009, 07:50
|

Нечётный пользователь.
     
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417

|
Цитата(_Pasha @ Feb 17 2009, 01:30)  Код typedef struct { uint16_t pc,sp,framePTR; } small_ctx_t; Т.е. для организации точки входа сопрограммы используется косвенный goto, указатель стека текущей сопрограммы и указатель на локальные данные, который можно получить __builtin_frame_ptr(0). Что-то в этом есть. В отличие от указателем на структуру с данным процесса-сопрограммы, это даёт возможность переключаться не только в "корневой" функции, но и в любом месте по глубине вызовов. Но это уже приведёт к потере части преимущества по стеку (да, все регистры уже не сохраняются, но для каждого сопроцесса нужно всё равно резервировать свой стек достаточной глубины). Правда, по сравнению с вытесняющмим системами, остаётся преимущество по времени синхронного переключения. А вот с асинхронным (из прерывания) - всё равно надо весь контекст сохранять, так как промежуточные вычисления на регистрах делаются, архитектура-то не стековая. Хотя для этого органичнее стековая архитектура. О которой ругаются в теме про архитектуру контроллера. На AVR такая модель не ложится, это на PDP-11 ещё можно было эмулировать - делать add 4(R3),8(R3) и только R3 да SP и сохранять (или вообще только SP для четырёх сопроцессов с базами в R0..R3, но они не смогли бы разделять между собой подпрограммы из-за разных баз), хотя, вероятно, выигрыш на переключении растерялся бы на проигрыше в эффектичности самих вычислений. Что-то я недоспал и всё не соображу. И уже бегу. Но интересно.
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
Feb 17 2009, 16:40
|

Нечётный пользователь.
     
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417

|
Цитата(_Pasha @ Feb 17 2009, 10:27)  Если вызываемые процедуры построены также. На счет стека - се ля ви - сколько процессов, столько и стеков.  Вот этого и не понимаю - "за что боролись". Стеки каждому свои. На стеке место нужно под всю глубину вызовов. Место под регистры на стеках не нужны только если все переключения задач синхронные. Если могут быть асинхронные переключения (из прерываний), то на стеках нужно место под полное сохранение контекста, с регистрами, так как прерывание может произойти в промежуточных операциях до записи результата в переменную на стеке. Итого при наличии асинхронных переключений экономии памяти на стеках нет вообще. При наличии только синхронных переключений эконоимия есть, но на не такая ощутимая. А время реакции наверное таки хуже, чем у вытесняющей ОС. Так что получается что-то среднее между - вызовом функции шага каждого процесса do_XXX_step(), делающей небольшой кусок работы и сохраняющей рещультат в статичесокй структуре состояния процесса
либо сопрограммными переключениями на верхнем уровне процесса, когда стек тоже в некотором смысле "очищен" - вытесняющей ОС
Причем у "среднего" память расходуется почти как у второго, а всё остальное - практически как у первого. Или я чего-то не понимаю по сонности своей в последние пару недель? --------------------------- Где-то пробегал линк на систему над автоматами, в которой (если я правилно помню, тогда пробежался по диагонали) всё происходит синхронно, при каждом автомате набор стандартных функций - "обычный" "сделать кусок", и "обработчики прерываний высокого уровня". У планировщика очередь, где стоят указатели на функции для автоматов которые надо выполнить и таймерные переменные (функция запускается кода дотикает). Кажется ещё приоритеты при этих указателях. В прерываниях делается самое быстрое типа сохранения байта UART в памяти и в очередь помещается указатель на соответствующий "обработчик высокого уровня" с флагом "как только, так сразу". Ну а планировщик после синхронного возврата из очередной функции пробегается по очереди и решает, по какому указателю вызвать следующую. Которая тоже может поместить в очередь нечто, например, "сигнальную" функцию от другого автомата. Всё чинно, синхронно, расход стека минимальный, никаких практически блокировок доступа к структурам не нужно, так как всё синхронно. Всё это сделано горстью макросов и выглядит довольно красиво и читабельно. Не уверен, что я правильно напел Битлз по телефону, но если кто-то таке встречал - дайте линк. А то у меня потерялся.
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
Mar 15 2009, 12:52
|

Нечётный пользователь.
     
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417

|
Цитата(ReAl @ Feb 17 2009, 18:40)  Не уверен, что я правильно напел Битлз по телефону, но если кто-то таке встречал - дайте линк. А то у меня потерялся. Шорт побори, это было TinyTimber (Vit aka sensor_ua показал когда-то) В прерываниях тоже всё работает - выходит, что обработчик прерывания сохраняет всё то, что не обязаны сохранять вызываемые подпрограммы, а планировщик в конце обработчика прерывания сохраняет через setjump остальное и по longjump переходт на другой процесс. Когда на данный процесс переключатся опять по longjump - оно всплывёт уже непосредственно перед эпилогом обработчика прерывания с восстановленными callee-saved регистрами, эпилог восстановит caller-saved и SREG. Всё пучком. Только в примере (по ссылке от Vit, эти исходники ненагугливаются по слову TinyTimber) сумма блока описания задачи (с буфером jumpbuf) и стека для задачи занимают где-то столько же, сколько и обычные стеки для AVR в scmRTOS, что вполне естественно. Т.е. явных преимуществ по памяти нет, оно, как уже отмечалось, было бы при только синхонном переключении и только на верхних уровнях, в "корневых" функциях автоматов (тогда на всех один стек). Если я правильно понял при беглом просмотре - преимущество просматривается в, фактически, диамическом создании/удалени задач, массивы описателей потоков и стеков - это массивы запущенных и выолняющегося плюс отложенных "методов", а не "процессов". Т.е. "спящий процесс" - это объект, у которого не запущен ни один "метод", т.е. никакой его код не работает, только сохраняется состояние автомата в его переменных, до которых ОС нет дела. А когда, например, "драйвер"-обработчик прерывания UART отошлёт весь пакет, тогда он из прерывания заланирует отработку соответствущего "метода" соответствующего "объекта" путём постановки "сообщения" в очередь. И он (метод) через сообщение привяжется к свободному блоку задачи/стеку, обработается через run() этого свободного "слота выполнения" (сразу или когда таковой освободится). Очередь сообщений TinyTimber тоже где-то эквиваленна по памяти набору событий/мьютексов, будет или нет преимущство зя счёт динамического распределения - тяжело сказать. И беда может обнаружиться только во время выполнения, а в случае scmRTOS просто при компиляции не хватит памяти для всех заявленных объектов ОС. Как-нибудь надо будет ещё покурить эту тему...
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
Sep 13 2009, 07:01
|
;
     
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509

|
Еще одна ТАСКАЛКА (от слова task) получилась. [attachment=36203:coos.zip] Несколько слов Код typedef struct Tag_TCB { void (*task)(struct Tag_TCB *tcb); void *param; void *entry; struct Tag_TCB *next; unsigned lock:1;// lock counter unsigned stop:1;// stop flag unsigned exit:1;// request to delete from list unsigned PID:5; // process ID } TCB_t; *param - для создания статических локальных переменных с учетом требований реентерабельности. *entry - для использования переопределяемых точек входа с помощью гнусной фичи labels as valuesВ общем - мне пока понравилась такая мысль: с одной стороны - через вызов system() можно отдавать управление другим задачам во время ожидания событий с другой стороны, чтоб не мучать стек обратными вызовами, можно использовать переопределяемые точки входа и смело выходить из задачи, пока не наступит нужное нам событие. Как Вам такой гибрид, уважаемый ReAl ? PS к тому же system() можно спрятать внутри любой реентерабельной функции, а точки входа - низзя. Теперь в TCB добавить поля для сообщений - и ось на подходе
|
|
|
|
|
Sep 13 2009, 09:21
|

Нечётный пользователь.
     
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417

|
Цитата(_Pasha @ Sep 13 2009, 10:01)  Еще одна ТАСКАЛКА (от слова task) получилась. Как Вам такой гибрид, уважаемый ReAl ? PS к тому же system() можно спрятать внутри любой реентерабельной функции, а точки входа - низзя. Да, system() некоторые вещи сделает красивее, но при этом если несколько задач из списка позовут system() (да ещё и из функции - а иначе кайфу в вызове system() никакого по сравнению с просто установокй метки и возвратом) - стек как-то глубоко пойдёт, надо помнить о возможности. В этом смысле вместо Код STD_TASK(wait2) { ENTRY(step1) { if(TCNT1 != 0xff00) system(); } } "стандартный" protothread-овский Код PT_WAIT_UNTIL(pt, TCNT1 != 0xff00); по стеку экономнее, так как ставит метку и даёт возврат из функции, а там уже просматривается список потоков. Никто не мешает комбинировать. И управляющую структуру я бы выделил в виде заголовка Код typedef struct Tag_TCB_header { void (*task)(struct Tag_TCB *tcb); void *entry; struct Tag_TCB *next; unsigned lock:1;// lock counter unsigned stop:1;// stop flag unsigned exit:1;// request to delete from list unsigned PID:5; // process ID // тут может ещё сразу таймерную переменную для таймаутов/sleep() } TCB_header_t; а локальные параметры не через указатель, а как продолжением структуры Код typedef struct tag_some_task_tcb { TCB_header_t th; unsigned some_param; unsigned char some_buf[8]; } some_task_tcb_t; при обращении не будет лишнего уровня косвенности. А вообще Vit на protothread-подобных вещах стаю собак сожрал, это с ним обсуждать надо.
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
Sep 13 2009, 11:55
|
;
     
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509

|
Цитата(ReAl @ Sep 13 2009, 12:21)  Да, system() некоторые вещи сделает красивее, но... Никто и не заставляет всюду им пользоваться  В тяжелых случаях перед вызовом должна быть проверка стека. Цитата В этом смысле вместо Код STD_TASK(wait2) { ENTRY(step1) { if(TCNT1 != 0xff00) system(); } } "стандартный" protothread-овский Не-не. Если есть ENTRY(), то можно обойтись без system() ЗЫ: Да и что толку от его тотального использования - в залоченном состоянии задача не обработает ни одного нового события. Код STD_TASK(wait2) { ALLOW_ENTRY; ................. ................ ENTRY(step1) { if(TCNT1 != 0xff00) return; /// просто вышли и попали опять в system() :) // а вот если тут был бы цикл с ожиданием - ясное дело, надо system() вызывать ................ ................ } } Отдельное спасибо за то, что напомнили про анонимные метки в PT_WAIT_UNTIL Добавлю. Но именные метки оставить надо, для возможного повторного использования точки входа. Цитата И управляющую структуру я бы выделил в виде заголовка а локальные параметры не через указатель, а как продолжением структуры при обращении не будет лишнего уровня косвенности. Имхо, правильнее просто передавать указатель на локальные переменные из system(), вместо полного TCB. Тогда обращение к полям TCB будет доступно только через осевые сервисы. Ага. И чтобы можно было пользоваться break /continue внутри ENTRY надо сделать Код #define ENTRY(label) tcb->entry = &&label; label: for(;;)
|
|
|
|
|
Sep 13 2009, 17:02
|

Нечётный пользователь.
     
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417

|
Цитата(_Pasha @ Sep 13 2009, 14:55)  Имхо, правильнее просто передавать указатель на локальные переменные из system(), вместо полного TCB. Тогда обращение к полям TCB будет доступно только через осевые сервисы. Ну и что в этом хорошего? Точнее, что хорошего в том, что эти сервисы вместо коротких inline-вызовов/макросов, обращающихся к полям TCB смещением к тому же указателю, который используеся для локальных переменных потока - вместо этого будут чем-то более толстым и медленным?
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
Sep 13 2009, 20:19
|
;
     
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509

|
Цитата(ReAl @ Sep 13 2009, 20:02)  Ну и что в этом хорошего? Ничего хорошего  Однако, чем проще TCB - тем реже он будет использоваться. Но сливать вместе заголовок и параметры не хоцца. Допустим, есть две пары одинаковых процессов - пишут данные в очередь и забирают . В этом случае имеем 2 функции, 2 пары заголовков в списке задач и два блока данных, описывающих очереди. Т.е. в каждой паре указатели на локальные параметры одинаковые - плодить сущности смысла нету. Все-таки есть смысл в первоначальной структуре заголовка, т.к void* param нуждается в типизации, которую и можно сделать при входе в функцию один раз. К тому же, задачи могут вообще не иметь локальных статических параметров. Как всегда - выбор между примерно равноправными вариантами...
|
|
|
|
|
Sep 14 2009, 08:58
|

Нечётный пользователь.
     
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417

|
Цитата(_Pasha @ Sep 13 2009, 23:19)  Допустим, есть две пары одинаковых процессов - пишут данные в очередь и забирают . В этом случае имеем 2 функции, 2 пары заголовков в списке задач и два блока данных, описывающих очереди. Т.е. в каждой паре указатели на локальные параметры одинаковые - плодить сущности смысла нету. У каждой очереди есть свой персональный блок указателей/флагов - для любого построения системы. А у двух одинаковых процессов локальные данные должны быть свои и указатели на локальные переменные не могут быть одинаковые. Вот эти локальные переменные в TCB пусть и сидят. А вот функция одна для обеих "писателей" и одна для обеих "читателей". Цитата(_Pasha @ Sep 13 2009, 23:19)  К тому же, задачи могут вообще не иметь локальных статических параметров. В этом случае для моего варианта в структуре TCB будет одно поле - заголовок.
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
Sep 15 2009, 06:42
|
;
     
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509

|
Кстати, о protothread parallel.h CODE #ifndef PARALLEL_H #define PARALLEL_H 1 #include <stddef.h>
typedef void* thread_t;
#define THREADFUNC thread_t __attribute__((noinline)) #define THREAD(name) if(name != NULL) goto *name static inline thread_t thread_label(void) __attribute__((always_inline));
thread_t thread_label(void) { __label__ lab; return &&lab; lab: ; }
#endif
Это есть самый минимальный набор для построения тредов. Это самый обрезанный и самый простой protothread-подобный в мире
|
|
|
|
|
Dec 25 2009, 08:47
|
;
     
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509

|
Решил скрестить прототредоподобную кооперативку и функцию system() или idle() или как там ея.. Я про блокировку рекурсивного вызова при использовании system() внутри треда . Получается вот что CODE #include <stddef.h> #define THREAD_LOCK (NULL+1)
static void *run1(void **lc) __attribute__((noinline)); static void *run2(void **lc) __attribute__((noinline)); void system(void) __attribute__((noinline));
void *run1(void **lc) {// min example void *pc = *lc; *lc = THREAD_LOCK; if(pc != NULL) goto *pc; return NULL; }
void system(void) { static void *pc1=NULL; if(pc1 != THREAD_LOCK) pc1 = run1(&pc1); static void *pc2=NULL; if(pc2 != THREAD_LOCK) pc2 = run2(&pc2); }
Немного кривовато, но по-другому не получается. Пробовал по-всякому - оптимизирует, зараза, начисто. А есть ли еще варианты блокировки без привлечения дополнительных переменных? upd: состояние THREAD_LOCK наверное лучше обозначить как pc = <адрес функции-треда> чтобы не влазить куда не надо.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|