Linux Kernel (Ядро линукса) (часть 1)

Примеры предотвращения конфликтов

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

Счетчики ссылок

Счетчики ссылок широко применяются в ядре для предотвращения конфликтов, возникающих из-за одновременного выделения и освобождения ресурса. Счетчик ссылок — это всего лишь счетчик типа atomic t, ассоциированный с некоторым ресурсом, таким как страница памяти, модуль или файл. Счетчик атомарно увеличивается, когда управляющий тракт ядра приступает к использованию ресурса, и уменьшается, когда он заканчивает пользоваться ресурсом. Когда счетчик ссылок становится равным нулю, ресурсом никто не пользуется, и его можно освободить, если это необходимо.

Глобальная блокировка ядра

В ранних версиях Linux широко применялась глобальная блокировка ядра (известная также как большая блокировка ядра, Big Kernel Lock). В Linux это была довольно жесткая спин-блокировка, в результате которой только один процессор мог работать в режиме ядра в данный момент времени. Код ядер 2.2 и 2.4 был намного более гибким и больше не полагался на единственную спин-блокировку. Разнообразные структуры данных ядра были защищены большим количеством различных спин-блокировок. В ядре Linux глобальная блокировка ядра применяется для защиты старого кода (в основном, функций, имеющих отношение к виртуальной файловой системе и к нескольким конкретным файловым системам).

Начиная с версии 2.6.11, глобальная блокировка ядра реализуется семафором по имени kernei sem (в предыдущих подверсиях версии 2.6 глобальная блокировка ядра была реализована с помощью спин-блокировки). Впрочем, глобальная блокировка ядра явление несколько более сложное, чем обычный семафор.

Каждый дескриптор процесса включает в себя поле lock depth, позволяющее одному процессу получать глобальную блокировку ядра несколько раз. Таким образом, два последовательных запроса на блокировку не подвесят процессор (как в случае с обычными блокировками). Если процессор не получил блокировку, это поле имеет значение -1; в противном случае значение поля, увеличенное на единицу, показывает, сколько раз была получена блокировка. Поле lock depth играет принципиальную роль при разрешении обработчикам прерываний, обработчикам исключений и функциям отложенного выполнения захватить глобальную блокировку ядра. Без этого поля любая асинхронная функция, пытающаяся получить глобальную блокировку ядра, могла бы создать взаимную блокировку, если у текущего процесса уже есть блокировка.

Функции lock kernel И unlock kernel ИСПОЛЬЗуЮТСЯ ДЛЯ получения И ОС- вобождения глобальной блокировки ядра.

Первая функция эквивалентна такому коду:

depth = current->lock_depth + 1; if (depth == 0)
down(&kernel_sem); current->lock_depth = depth;
а вторая — такому:
if (—current->lock_depth riim[RLiMiT_cpu] .riim cur каждого дескриптора процесса;
• вызывает функции account it virt() и account it prof о, чтобы проверить таймеры процесса
• обновляет некоторые статистические данные ядра, хранящиеся в переменной kstat, имеющейся у каждого процессора.
2. Вызывает функцию raise softirqO, чтобы активизировать тасклет timer softirq на локальном процессоре
3. Если необходима утилизация какой-то старой версии некоторой структуры, защищенной с помощью механизма RCU, функция проверяет, перешел ЛИ процессор В состояние ПОКОЯ, И вызывает функцию tasklet_schedule, чтобы активизировать тасклет rcu taskiet на локальном процессоре
4. Вызывает функцию scheduier tick , которая уменьшает для текущего процесса счетчик отрезка времени и проверяет, истек ли квант