Требуется совет по выбору RTOS, программист я хреновый Опции

[Electrovoicer]

Созревает проект на LPC213x. Сюдя по всему конечным автоматом на таймере обойтись не получится ввиду большого числа событий и источников прерываний. Это на мой профанский взгляд. Да и надо наконец научиться писать с использованием RTOS. В связи с чем просьба к общественности посоветовать ПРОСТУЮ RTOS. И не просто посоветовать, а подсказать где ее взять. В принципе и купить можно, но сначала хотелось бы пощупать. Главное чтобы софт был качественно задокументирован, а то в С++ я как свинья в апельсинах, разбираться с исходниками не буду да и не смогу наверное. Мне бы на пальцах показать, как создать тред и исполнить в нем мой код. Соответственно хотелось бы иметь готовый порт на мой процик. Вытесняющая она должна быть или невытесняющая, еще не понял. Чтобы это понять, желательно Ваши примеры задач, для которых то или иное больше подходит.
Также просьба не отвечать вроде "да на хрена тебе ртос", "атмел sam7 рулит" и "ваще надо на асме писать"

С уважением, я

[vet]

http://en.wikipedia.org/wiki/Critical_section

[sensor_ua]

Насчет "сложнее и ненадежнее", то интересны аргументы. Если только "персональность" переменной для хранения статуса, то уже обсуждали.

Еще раз повторить?
1. Сложнее - вместо простейшей обертки над стандартной де-факто библиотечной функции гарантированно работающей на любом процессоре. Писанная на асме чисто армовсая, да еще с заточкой под ARM Mode
2. Ненадежнее - легко ошибиться (особенно не зная потрохов и соответствено границ применимости)
при использовании вложеных критических секций. Про macros писал - ну просто подстава чистейшей воды. Практически использование недалеко ушло от аккуратного использования пресловутого запрещения прерывания.

А насчет "Простое запрещение прерываний" хотелось бы отклониться в сторону

А ненадо отклоняться, ибо все равно оно имеет место быть.

Это TNKernel:

Код

tn_cpu_save_sr:

        mrs    r0,CPSR
        orr    r1,r0,#NOINT
        msr    CPSR_c,r1
;-- Atmel add-on
        mrs    r1,CPSR            ;-- Check CPSR for correct contents
        and    r1,r1,#NOINT
        cmp    r1,#NOINT
        bne    tn_cpu_save_sr     ;-- Not disabled - loop to try again
;--------

        bx     lr

Это кусок IARовской библиотеки:

Код

        cfi_ARM_BLOCK_start disableInterrupt_a
        
        CODE32
??DiI_a        
        mrs        r12,CPSR
        orr        r12,r12,#0xC0
        msr        CPSR_c,r12

        mrs   r12,CPSR
    ands  r12,r12,#+0xC0    
        beq   ??DiI_a

        bx        lr

        cfi_ARM_BLOCK_end disableInterrupt_a

Как Вам разница?

Мои познания в асме закончились на #+0xC0.
Вообще же, как по мне - не очень-то и разнится код - похоже, смысл тот же.
Правда чуть короче запись.
Пока пороюсь поищу что такое #+0xC0, а то "чукча не читатель";)))
Может подскажете, где? А то ARM7TDMI Data Sheet (ARM DDI 0029E) не помогает...

[DASM]

http://en.wikipedia.org/wiki/Critical_section

Глупость это. Причем тут КОД ? Представьте себе 128 экземпляров некоего класса. Код у них один и тот же, разные у них данные. Пусть объект один захватил за попку одну девушку (разделяемый ресурс, вошел в свою критическую секцию) Да, это не даст другим экземплярам трогать туже поку, но разве это запрещает другим экземплярам лапать другие попы ? В том же участке кода, теми же руками. Просто Критические секции будут разными, разными объектами в памяти. И запрещать тут прерывания - форменное свинство.

[vet]

Продолжаю цитирование.
A solution to the critical section problem, first posed by Dijkstra [1], is a fundamental requirement for concurrent program control. The problem is to ensure that no two processes are in a specified area of their programs (the critical section) at the same time.

[DASM]

Продолжу несогласие, Критическая секция защишает РЕСУРС а не код, который исполняется (его вообще защищать не надо)

[zltigo]

Вообще же, как по мне - не очень-то и разнится код - похоже, смысл тот же.

Ага, для этого вывода и приводились эти куски. Только один почему-то в результате "анализа"
был признан непонятным и некошерным. Что меня и удивило и подвигнуло на мой первый пост.
Вот собственно и все.

[vet]

DASM
Ресурс можно защищать и мьютексами, они для этого и придуманы. А критическая секция придумана для немного других вещей, на что и указывает цитируемый классик. В частности - для обеспечения реентерабельности кода, мьютексом её делать немного не с руки, а КС - в самый раз.

[Andy Mozzhevilov]

А DASM вроде как прав получается, касательно критической секции.
Если Таненбаума книгу "Современные ОС" посмотреть, так там написано, что
Критическая секция служит для того, чтобы предотвратить одновременный доступ к обшим данным. Одно из требований, это то, что в критической области не могут находиться одновременно 2 процесса.
Но для этого действительно не обязательно запрещать прерывания. Поток находящийся в крит.секции, может вытесниться, но если какой другой поток захочет в нее войти, он должен ожидать пока она освободится.

В общем, спор о терминах.
В принципе можно называть критической секцией любую секцию, где предотвращается одновременный доступ к каким-либо ресурсам из разных процессов. Способ реализации может быть, как методом запрета прерываний, так и с организацией доступа через бинарный семафор (или можно применить модное слово мютекс ) или какой-нибудь флаг.
Причем иногда доступ запретом прерываний вообще может оказаться не приемлем, потому как ресурс, доступ к которому разделяется, может сам работать через прерывания, например захватили uart, передали строку символов, освободили uart. Понятно, что разделить доступ к такому ресурсу через запрет прерываний нельзя.
Другое дело, когда надо сделать действие, достаточно короткое и быстрое, но требующее также гарантий ограничения доступа к этом ресурсу. Например, работа со связанными списками. Вставка элемента списка в цепочку должна быть сделана в критической секции. Но пользование в этом случае системных сервисов ОС (типа мютексов) - нецелесообразно, потому как накладные расходы возрастут раз в 100 по сравнению с методом разрешения/запрещения прерываний.
И совсем другое дело, когда говорится о критических секциях, используемых в самой ОС, то есть когда сервисы ОС прописываются. Здесь термин "критическая секция" как раз всегда означает запрещение прерываний. А речь как раз о них и была (выше по теме).
У меня терминология (моя локальная) устоялась так, что критической секцией я называю секцию, где запрещены прерывания, и не важно, используется в проекте ОС или нет.

Пока пороюсь поищу что такое #+0xC0, а то "чукча не читатель";)))
Может подскажете, где? А то ARM7TDMI Data Sheet (ARM DDI 0029E) не помогает...

#0xC0 маска для запрета IRQ и FIQ прерываний
Маска 0x80 для регистра CPSR - это запрет IRQ , а 0x40 - для запрета FIQ.

[DASM]

тогда предлагаю прямо и говорить "я называю критической секцией стакан с пивом, поэтому у нас несогласованность терминологий"
Простенький пример, скажите, что тут защищает КОД ??

Код

CRITICAL_SECTION cs;
CRITICAL_SECTION cs1;
//
struct common_struct{
    int a;    
    CRITICAL_SECTION* myGuard;
};
//
DWORD WINAPI MyThread (LPVOID *p)
{
    common_struct *pstruct = (common_struct *)p;
    for (;;)
    {
        EnterCriticalSection(pstruct->myGuard);
        pstruct->a++;
        LeaveCriticalSection(pstruct->myGuard);
        Sleep(0);
    }
    return 0;
}
//
int _tmain(int argc, _TCHAR* argv[])
{
    DWORD dwID = 0;
    common_struct com1 =  {0, &cs}, com2 = {0, &cs1};
    InitializeCriticalSection(&cs); InitializeCriticalSection(&cs1);
    HANDLE hMyThr1 = CreateThread (NULL, 0, (LPTHREAD_START_ROUTINE)MyThread, &com1, CREATE_SUSPENDED, &dwID);
    HANDLE hMyThr2 = CreateThread (NULL, 0, (LPTHREAD_START_ROUTINE)MyThread,  &com2, CREATE_SUSPENDED, &dwID);
    ResumeThread(hMyThr1);
    ResumeThread(hMyThr2);
    for (;;)
    {
    }
    return 0;
}

[sensor_ua]

У меня железка с неким ногодрыганием, устроенным типа импровизированной шины. Как известно, GPIO сами не имеют в АРМ операций чтение-модификация-запись, дык ещё в железке есть выборки внешних устройств на "шине" через опять же GPIO. Если подвигать GPIO в прерывании, а оно может возникнуть когда двигались GPIO вне прерывания, чегой-то нужно сохранять. Т.е. либо в административном порядке запрещать использовать GPIO в прерывании, либо реализовать атомарность каким-либо способом. АРМ позволяет, например, выполнить SWI, можно просто запрещать прерывания на входе в критическую секцию, при выходе - разрешать, но тогда если при входе если были запрещены прерывания, при выходе они разрешатся... иначе нужно при входе не просто запрещать, а сохранять регистр статуса, затем запрещать прерывания, а при выходе всего-лишь восстанавливать что было. Можно вообще завести обработчик IRQ, в который вваливаться через VICSoftInt, а там творить чего угодно, пока не разрешили вложенные прерывания...

А DASM вроде как прав получается, касательно критической секции.
Если Таненбаума книгу "Современные ОС" посмотреть, так там написано, что
Критическая секция служит для того, чтобы предотвратить одновременный доступ к обшим данным. Одно из требований, это то, что в критической области не могут находиться одновременно 2 процесса.
Но для этого действительно не обязательно запрещать прерывания. Поток находящийся в крит.секции, может вытесниться, но если какой другой поток захочет в нее войти, он должен ожидать пока она освободится.

В общем, спор о терминах.
В принципе можно называть критической секцией любую секцию, где предотвращается одновременный доступ к каким-либо ресурсам из разных процессов. Способ реализации может быть, как методом запрета прерываний, так и с организацией доступа через бинарный семафор (или можно применить модное слово мютекс ) или какой-нибудь флаг.
Причем иногда доступ запретом прерываний вообще может оказаться не приемлем, потому как ресурс, доступ к которому разделяется, может сам работать через прерывания, например захватили uart, передали строку символов, освободили uart. Понятно, что разделить доступ к такому ресурсу через запрет прерываний нельзя.
Другое дело, когда надо сделать действие, достаточно короткое и быстрое, но требующее также гарантий ограничения доступа к этом ресурсу. Например, работа со связанными списками. Вставка элемента списка в цепочку должна быть сделана в критической секции. Но пользование в этом случае системных сервисов ОС (типа мютексов) - нецелесообразно, потому как накладные расходы возрастут раз в 100 по сравнению с методом разрешения/запрещения прерываний.
И совсем другое дело, когда говорится о критических секциях, используемых в самой ОС, то есть когда сервисы ОС прописываются. Здесь термин "критическая секция" как раз всегда означает запрещение прерываний. А речь как раз о них и была (выше по теме).
У меня терминология (моя локальная) устоялась так, что критической секцией я называю секцию, где запрещены прерывания, и не важно, используется в проекте ОС или нет.

Пока пороюсь поищу что такое #+0xC0, а то "чукча не читатель";)))
Может подскажете, где? А то ARM7TDMI Data Sheet (ARM DDI 0029E) не помогает...

#0xC0 маска для запрета IRQ и FIQ прерываний
Маска 0x80 для регистра CPSR - это запрет IRQ , а 0x40 - для запрета FIQ.

Простите, не указал точно - мне непонятно только "#+"

[Andy Mozzhevilov]

Простите, не указал точно - мне непонятно только "#+"

Ну, это значит "не минус"

тогда предлагаю прямо и говорить "я называю критической секцией стакан с пивом, поэтому у нас несогласованность терминологий"
Простенький пример, скажите, что тут защищает КОД ??

понятия не имею.

[sensor_ua]

Ну, это значит "не минус" smile.gif

Спасибо.

[zuy]

to: Andy Mozzhevilov
Действительно реализация крит.секций может быть как с прерываниями так и без. Но применительно к ОС (мы же в этой теме рассматриваем именно прерывания для организации крит.секции в ОС) имеет место быть целый параграф у Таненбаума. В в итоге он пишет, что запрет прерываний, бывает полезным при использовании крит.секции в самой ОС, но это решение не приемлемо в качестве механизма взаимного исключения для пользовательских процессов.

To DASM:
Пример IMHO не совсем корректен. Т.к. проблема синхронизации ставится при опастности свместного использования одних и тех же данных, и именно это общие данные защишаются запретом исполнения кода который их использует. А в Вашем примере, если я конечно правильно понял, две КС защищают каждая свои данные. Т.е. конкуренции то нет.

[DASM]

правильно, конкуренции нет, но КУСОК КОДА то исполняется конкурентно ? Что и требовалсь показать. Всего лишь

[zuy]

Ааааа, все, понял к чему пример.
Как раз к прерываниям в КС. Все верно, если бы КС делалась через запрет прерывания, то тут была бы лажа, потоки бы блокировались без нужды.