2010-09-03 2 views
5

http://lxr.linux.no/linux+v2.6.35/include/linux/preempt.h#L21Как линукс синхронизирует Preempt граф

Я просто пытаюсь получить источник Linux. Я видел это количество предикатов и как linux гарантирует, что количество упреждающих вычислений является атомарным? Код просто увеличивает значение.

Также у меня есть еще один вопрос. почему ручки прерывания должны поддерживать взаимное исключение. Потому что только один может выполнить сразу?

Также, когда прерывания отключены, что делает ОС? Игнорировать прерывания или поддерживать очередь?

ответ

6

Это увеличивает preempt_count() - обратите внимание на () - что макрос определяется как:

#define preempt_count() (current_thread_info()->preempt_count) 

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


Это лучше спросить ваши многочисленные вопросы, как отдельные вопросы, но вкратце:

  • Обработчики прерываний в общем случае может быть прервана другими обработчики прерываний;
  • Обработчики прерываний могут работать на одном ядре процессора, а другой код ядра работает на другом ядре;
  • Прерывания обычно отключены с помощью аппаратного механизма. Они, как правило, запоминают ожидающие прерывания, но не более одного на один вектор прерывания.
+0

Большое спасибо. вы можете ответить на мои следующие вопросы тоже PLS. – mousey

+0

большое спасибо. – mousey

+0

@caf и mousey: Если inc/dec также вызывается обработчиками ошибок или обработчиками прерываний, было бы безопасно? Или есть какие-то правила, говорящие, что это невозможно? Идеи? – minghua

0

Каждый современный процессор имеет некоторый вариант атомной инструкции test-and-set.

+1

проверить источник. Он не использует никаких конкретных инструкций системы. Он просто увеличивает – mousey

1

Операция над переменной preempt_count не является атомарной. Область кода между inc и dec из preempt_count потока гарантированно не будет отключена планировщиком. Контекстное переключение из текущего потока в этой области кода может произойти только в последующих встроенных исключениях или прерываниях. После завершения первой операции inc дальнейшие обработчики будут видеть, что переменная не равна нулю, поэтому не вызывает контекстный переключатель. Перед тем, как инк заканчивается, нить может быть отключена, но это нормально, поскольку код не достиг защищенной области.

Некоторые детали: Определение атомной переменной должно быть чем-то вроде "Atomic variables are the ones on whom the read modify write operation is done as one instruction with out any interruption". Операция «Read-Modify-Write» на preempt_count может быть прервана другим обработчиком исключений или обработчиком прерываний, но только строго встроенным способом, то есть дизайном ядра. Поскольку эти встроенные операции находятся в парах, таким образом, значение preempt_count в конечном итоге не будет искажено. Хотя операция R-M-W может быть прервана и текущий поток может быть отключен (только если ни один из нескольких встроенных инк не завершился), но это нормально, поскольку код не достиг защищенной области. Как только нить будет переключена назад, она продолжит завершение работы R-M-W и с этой точки на текущей нити не будет отключена, пока все парные dec (s) не закончатся.

Смежные вопросы