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

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

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

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

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




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

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

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


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

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


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

Спасибо.

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

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

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

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