а мне всегда казалось, что назначение критических секций - это не допустить одновременного использования одного расшаренного ресурса разными потоками...... Про прерывания течения кода как-то читать не доводилось... Где я могу просветить свою темноту ?

-Ну про 'навороты' это уж перебор :-)
-Безболезненная вложенность.
-При использовании этого механизма без левых запретов прерывания будет отсутствовать
это:



Одного порядка, на самом деле, в FreeRTOS случае дополнительная работа со счетчиком
в памяти, в варианте "с сохранением" тоже работа с памятью - считать-запомнить-прочитать-записать.


-Увы, не единственное, вроде уже распинался :-(.
- в варианте "со счетчиком" комплементарность можно слегка нарушить :-) лишними вызовами
конца критической секции.



У меня не ассоциируется, просто здесь речь идет о двух реалиациях оных в двух конкретных
системах, которые обе базируются на таком решении. Обсуждаются отличия, причем автором
во главу угла была поставлена (если я правильно все это понимаю) мнимая большая дуракоустойчивость TNKernel в сравнении c FreeRTOS.

Нет, этот сервис предоставляется семафорами.



Да хоть не любимого тобой Лябрусса , книгу по uCOS

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

Andy , ты перепутал семафор с мьютексом. К тому же критическая секция нужна именно для того что я сказал. Дж.Рихтер "Windows для профессионалов". Цитировать или веришь ? И совет - не читайте Лябруса :-D

Из двух зол, книга автора uCOS явно меньшее :-)

А книжек по Виндоуз я вообще читать эбмеддерам не советую ))

Извините за ошибки распознования текста finereader -ом
Семафоры
Объекты ядра «семафор» используются для учета ресурсов. Как и все объекты ядра они содержат счетчик числа пользователей, но, кроме того, поддерживают два 32-битных значения со знаком: одно определяет максимальное число ресурсов (контролируемое семафором), другое используется как счетчик текущего числа ресурсов.

Мьютексы
Объекты ядра «мьютексы» гарантируют потокам взаимоисключающий доступ к единственному ресурсу. Отсюда и произошло название этих объектов (mutual exclusion, mutex). Они содержат счетчик числа пользователей, счетчик рекурсии и переменную', в которой запоминается идентификатор потока. Мьютексы ведут себя точно так же, как и критические секции. Однако, если последние являются объектами пользовательского режима, то мьютексы — объектами ядра. Кроме того, единственный объект-мью-текс позволяет синхронизировать доступ к ресурсу нескольких потоков из разных процессов; при этом можно задать максимальное время ожидания доступа к ресурсу.

Критические секции
Критическая секция (critical section) — это небольшой участок кода, требующий монопольного доступа к каким-то общим данным. Она позволяет сделать так, чтобы единовременно только один поток получал доступ к определенному ресурсу. Естественно, система может в любой момент вытеснить Ваш поток и подключить к процессору другой, но ни один из потоков, которым нужен занятый Вами ресурс, не получит процессорное время до тех пор, пока Ваш поток не выйдет за границы критической секции.

Насчет то чего читать - давай тогда Дейкстру поднимем, как основателя теории синхронизации.... Лябрус он больше по рюшечкам, сеггеру, и безумным ГУЯм

В варианте с сохранением/восстановлением аналогично - вложенность безболезненная.

Зато есть ограничение - нельзя самому рулить состоянием прерываний.


Ну да, тут в корне меньше - записал в память, на выходе извлек. А со счетчиком - прочитал, проинкрементировал, записал. (на входе), прочитал, проанализировал, сделал переход (а переход сам по себе наклАдная инструкция, и чем толще проц, тем она наклАднее), декрементировал, записал обратно в память. Фигассе! Вот реализация по схеме сохранил/восстановил для AVR:
Вход:

выход


Что может быть короче и нативнее?


Прошу прощения, я как-то пропустил это. Можно для меня напомнить что там не единственное?


Как это нарушить? Т.е. вход вызвали 3 раза и выход 4? Но ведь при этом работать-то оно будет неправильно - прерывания будут разрешены не в том месте, где были запрещены.

ДАЕШЬ 64-битную WIndows в embedded !!!

Ну а теперь "на бис" для ARM, о которых здесь речь :-). И не в регистр сохранять. В ARM с памятью поработать - много хуже :-(. И заменитель 'CLI' выглядит тоскливо (выше приводил кусок кода). Зато у ARM "переходы" через несколько команд могут начисто отсутствовать. В результате разница будет крайне невелика.


Либо руками (Про C++ - не надо, я в курсе) будете выделять индивидуальную память для сохранения текущего зачения при каждом вызове, либо не будет вложенности. Про комплиментарноть - ниже.


Хоть 444 раза - посмотрите код - действия просто будут проигнорированы, в отличие от варианта
"с сохранением" в котором будет упорно переписываться последнее сохраненное бог всесть когда
значение, а если еще и в регистре сохранить :-)

мда... я примерно одно слово понял из всего написаного выше... может мне не надо ОС? =)

не всякий автомобилист знает, как устроена автомат коробка передач...

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

ну так еще бы Рихтер был не прав..