Про реентерабельность, малоизвестная фича GCC Опции

[_Pasha]

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

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

Код

void somefunc (volatile int param)
{ 
  volatile int local1;
  volatile char local2;
//body
local1 |= param;
return;
}

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

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

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

[_Pasha]

Еще одна ТАСКАЛКА (от слова 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 добавить поля для сообщений - и ось на подходе

[ReAl]

Еще одна ТАСКАЛКА (от слова 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-подобных вещах стаю собак сожрал, это с ним обсуждать надо.

[_Pasha]

Да, 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(;;)

[ReAl]

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

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