Что происходит, когда задача выполняет критическую секцию, но ее необходимо запланировать в однопроцессорной системе с отключенным вытеснением? - PullRequest
0 голосов
/ 24 января 2019

Вот сценарий. Предположим, что задача ядра выполняется в однопроцессорной системе с отключенным вытеснением. Задача приобретает спиновый замок. Сейчас он выполняет свой критический раздел. В это время, что, если временной интервал, доступный для этой задачи, истекает, и это должно запланировать?

  1. Есть ли у spin_lock механизм для предотвращения этого?
  2. Это можно запланировать? Если да, то что происходит с критическим разделом?
  3. Может ли оно быть прервано IRQ? (Предполагая, что выгрузка отключена)
  4. Возможен ли этот сценарий? Другими словами, может ли этот сценарий произойти?

Из кода ядра я понимаю, что spin_lock - это в основном nop на однопроцессорном компьютере с отключенным вытеснением. Чтобы быть точным, все, что он делает, это barrier() Я понимаю, почему это nop (поскольку он является однопроцессорным, и никакая другая задача не могла манипулировать данными в этот момент), но я до сих пор не понимаю, как это может быть непрерывно (из-за прерываний или планирования). Что мне здесь не хватает? Указатели на код ядра Linux, которые указывают на это, могут быть очень полезны.

Мои основные предположения:

32-битное ядро ​​Linux

1 Ответ

0 голосов
/ 25 января 2019

На самом деле spin_lock() отключает вытеснение, вызывая preempt_disable(), прежде чем попытается получить блокировку, поэтому сценарий № 1, № 2, № 3 никогда не может произойти.Из недавнего исходного кода spin_lock () в конечном итоге вызывает __ raw_spin_lock () , который вызывает preempt_disable() перед вызовом spin_acquire() для получения блокировки.spin_lock_irqsave(), который обычно используется в контексте прерывания, имеет аналогичный контекст.

Что касается # 3, если переменная является общей для контекста процесса / прерывания, вы всегда должны использовать spin_lock_irq()/spin_lock_irqsave() вместо spin_lock(), чтобы избежать тупикасценарий.

...