WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 10 |

«; ...»

-- [ Страница 4 ] --

work = list_entry(cwq->worklist.next, struct work_struct, entry)

;

f = work->func

;

data = work->data

;

list_del_init(cwq->worklist.next)

;

clear_bit(0, &work->pending)

;

f(data)

;

} 152 Глава Эта функция просматривает в цикле все элементы списка отложенных действий и выполняет для каждого элемента функцию, на которую указывает поле func соответ ствующей структуры workqueue_struct. Последовательность действий следующая.

• Если список не пустой, получить следующий элемент списка.

• Получить указатель на функцию (поле func), которую необходимо вызвать, и аргумент этой функции (поле data).

• Удалить полученный элемент из списка и обнулить бит ожидания в структуре элемента.

• Вызвать полученную функцию.

• Повторить указанные действия.

Извините, если не понятно Взаимоотношения между различными, рассмотренными в этом разделе структу рами достаточно запутанные. На рис. 7.1 показана диаграмма, которая эти взаимоот ношения поясняет.

На самом верхнем уровне находятся рабочие потоки. Может существовать не сколько типов рабочих потоков. Для каждого типа рабочих потоков существует один рабочий поток для каждого процессора. Различные части ядра при необходимости могут создавать рабочие потоки. По умолчанию выполняются только рабочие по токи events (события). Каждый рабочий поток представлен с помощью структуры cpu_workqueue_struct. Структура workqueue_struct представляет все рабочие потоки одного типа.

По одному экземпляру Структура Рабочий поток на процессор cpu_workqueue_struct Структура Один экземпляр на каждый workqueue_struct тип рабочих потоков Структура Один экземпляр work_struct на каждую функцию отложенного действия Рис. 7.1. Соотношения между отложенными действиями, очередями, дей ствий и рабочими потоками Обработка нижних половин и отложенные действия Например, давайте будем считать, что в дополнение к обычному типу рабочих потоков events был создан еще один тип рабочих потоков — falcon. Также имеется в распоряжении четырехпроцессорный компьютер. Следовательно, выполняется че тыре потока типа events (соответственно, определено четыре экземпляра структуры cpu_workqueue_struct) и четыре потока типа falcon (для которых тоже опреде лены другие четыре экземпляра структуры cpu_workqueue_struct). Для потоков типа events определен один экземпляр структуры workqueue_struct, а для потоков типа falcon — другой экземпляр этой структуры.

На самом нижнем уровне находятся отложенные действия. Драйвер создает от ложенное действие, которой должно выполниться позже. Действия представлены структурами work_struct. Кроме других полей, эта структура содержит указатель на функцию, которая должна обработать отложенное действие. Отложенное действие отправляется на выполнение определенному потоку. Соответствующий поток перево дится в состояние выполнения и выполняет отложенную работу.

Большинство драйверов использует существующие по умолчанию рабочие пото ки, которые называются events. Они просты в реализации и в использовании. Однако в некоторых, более серьезных ситуациях необходимо создавать новые специальные рабочие потоки. Например, драйвер файловой системы XFS создает два новых типа рабочих потоков.

Использование очередей отложенных действий Использовать очереди действий просто. Сначала мы рассмотрим рабочие пото ки, используемые по умолчанию, — events, а затем опишем создание новых типов ра бочих потоков.

Создание отложенных действий Первый этап — это создание самого действия, которое должно быть отложено.

Для создания статической структуры на этапе компиляции необходимо использовать следующий макрос.

DECLARE_WORK(name, void (*func) (void *), void *data)

;

Это выражение создает структуру works_t ruct с именем name, с функцией обработчиком func и аргументом функции-обработчика data.

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

INIT_WORK(struct work_struct *work, void (*func)(void *),void *data)

;

Этот макрос динамически инициализирует отложенное действие, на структуру которого указывает указатель work, устанавливая функцию-обработчик func и аргу мент data.

Обработчик отложенного действия Прототип обработчика отложенного действия имеет следующий вид.

void work_handler (void *data) 154 Глава Рабочий поток выполняет эту функцию, и, следовательно, эта функция выполня ется в контексте процесса. По умолчанию при этом вес прерывания разрешены и никакие захваченные блокировки не удерживаются. Ели это необходимо, то функция может переходить в состояние ожидания. Следует заметить, что несмотря на то, что обработчики отложенных действий и выполняются в контексте процесса, эти обра ботчики не могут переходить в пространство пользователя, так как у потоков про странства ядра нет адресного пространства пользователя. Ядро может обращаться в пространство пользователя, только когда оно выполняется от имени пользователь ского процесса, который имеет адресное пространство пользователя, отображенное на память, как, например, в случае выполнения системного вызова.

Блокировки между очередями отложенных действий и другими частями ядра осу ществляются также, как и в случае любого другого кода, работающего в контексте процесса. Это позволяет сделать написание обработчиков отложенных действий до статочно простым. В следующих двух главах это раскрывается более детально.

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

г schedule_work(&work)

;

Действие планируется на выполнение немедленно и будет выполнено, как только рабочий поток events, работающий на данном процессоре, перейдет в состояние выполнения.

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

schedule_delayed_work (&work, delay)

;

В этом случае действие, представленное структурой work_struct, с адресом &work, не будет выполнено, пока не пройдет хотя бы заданное в параметре delay количество импульсов таймера. О том, как использовать импульсы таймера для из мерения времени, рассказывается в главе 10, "Таймеры и управление временем".

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

Для этого есть следующая функция, которая позволяет ждать, пока очередь дей ствий events не будет очищена.

void flush_scheduled_work(void)

;

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

Заметим, что эта функция не отменяет никаких отложенных действий с задерж ками. Любые действия, которые запланированы на выполнение с помощью функции schedule_delayed_work () и задержки которых еще не закончены, — не очищаются с помощью функций flush_scheduled_work (). Для отмены отложенных действий с задержками следует использовать функцию int cancel_delayed_work(struct work_struct *work)

;

Эта функция отменяет отложенное действие, которое связано с данной структу рой work_struct, если оно запланировано.

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

Новая очередь действий и связанные с ней рабочие потоки создаются с помощью простого вызова функции.

struct workqueue_struct *create_workqueue(const char *name)

;

Параметр name используется для того, чтобы присваивать имена потокам ядра.

Например, очередь events, которая используется по умолчанию, создается с помо щью следующего вызова.

struct workqueue_struct *keventd_wq = create_workqueue("events")

;

При этом также создаются все рабочие потоки (по одному на каждый процессор), которые подготавливаются к выполнению работы.

Создание отложенных действий выполняется одинаково, независимо от тина очереди. После того как действия созданы, могут быть использованы функции, ана логичные функциям schedule_work() и schedule_delayed_work(), которые от личаются тем, что работают с заданной очередью действий, а не с очередью, ис пользуемой по умолчанию.

int queue_work struct workqueue_struct *wq, struct work_struct *work)

;

int queue_delayed_work(struct workqueue_struct *wq, struct wesrk_struct *work, unsigned long delay)

;

И наконец, ожидание завершения действий в заданной очереди может быть вы полнено с помощью функции flush_workqueue(struct workqueue_struct *wq)

;

Эта функция работает по аналогии с функцией flush_scheduled_work (), как описывалось ранее, за исключением того, что она ожидает, пока заданная очередь не станет пустой.

156 Глава Старый механизм очередей заданий Так же как и в случае интерфейса ВН, который дал начало интерфейсам отложен ных прерываний (softirq) и тасклетов (tasklet), интерфейс очередей действий возник благодаря недостаткам интерфейса очередей заданий (task queue). Интерфейс оче редей заданий (который еще называют просто tq), так же как и тасклеты, не имеет ничего общего с заданиями (task), в смысле с процессами8. Все подсистемы, которые использовали механизм очередей заданий, были разбиты на две группы еще во вре мена разработки серии ядер 2.5. Первая группа была переведена на использование тасклетов, а вторая— продолжала использовать интерфейс очередей заданий. Все, что осталось от интерфейса очередей заданий, перешло в интерфейс очередей отло женных действий. Краткое рассмотрение очередей заданий, которым пользовались в течение некоторого времени, — это хорошее упражнение по истории.

Интерфейс очередей заданий позволял определять набор очередей. Очереди имели имена, такие как scheduler queue (очередь планировщика), immediate queue (немедленная очередь) или timer queue (очередь таймера). Каждая очередь выпол нялась в определенных местах в ядре. Поток пространства ядра keventd выполнял работу, связанную с очередью планировщика. Эта очередь была предшественником интерфейса очередей отложенных действий. Очередь таймера выполнялась при каж дом импульсе системного таймера, а немедленная очередь выполнялась в нескольких местах, чтобы гарантировать "немедленное" выполнение. Были также и другие оче реди. Кроме того, можно было динамически создавать новые очереди.

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

Еще одним преимуществом механизма очередей заданий была простота интер фейса. Несмотря на большое количество очередей и разнообразие правил, по кото рым они выполнялись, интерфейс был максимально прост. Все остальное, что каса ется очередей заданий, необходимо было убрать.

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

;

большинство — тасклетами. Осталось только то, что касалось очереди планировщика. В конце концов, код демона keventd был обобщен в отличный механизм очередей действий, который мы имеем сегодня, а очереди за даний были полностью удалены из ядра.

Какие обработчики нижних половин необходимо использовать Решение о том, какой из механизмов обработки нижних половин следует исполь зовать, является важным. В современных ядрах серии 2.6 есть три варианта выбора:

отложенные прерывания (softirq), тасклеты (tasklet) и очереди отложенных действий (work queue). Тасклеты построены на основе отложенных прерываний, и поэтому Названия для механизмов обработки нижних половин, очевидно, выбираются из соображений конспирации, чтобы сбивать с толку молодых и неопытных разработчиков ядра.

Обработка нижних половин и отложенные действия эти два механизма похожи. Механизм очередей действий полностью от них отлича ется, он построен на базе потоков пространства ядра.

Благодаря своей реализации, отложенные прерывания обеспечивают наибольший параллелизм. Это требует от обработчиков отложенных прерываний применения до полнительных мер для того, чтобы гарантировать безопасный доступ к совместно используемым данным, так как два или более экземпляров одного и того же отло женного прерывания могут выполняться параллельно на разных процессорах. Если код уже очень хорошо распараллелен для многопоточного выполнения, как, напри мер, сетевая подсистема, которая использует данные, связанные с процессорами, то использование отложенных прерываний— это хороший выбор. Они, конечно, пред ставляют собой наиболее быстрый механизм для критичных ко времени или частоте выполнения задач. Тасклеты имеет больший смысл использовать для кода, который не очень хорошо распараллелен для многопоточности. Они имеют более простой интерфейс, и поскольку тасклеты одного типа не могут выполняться параллельно, то их легко программировать. Тасклеты — это фактически отложенные прерывания, которые не могут выполняться параллельно. Разработчики драйверов всегда должны использовать тасклеты, а не отложенные прерывания, кроме, конечно, случаев, ког да они готовы связываться с такими вещами, как переменные, связанные с процес сорами (рег-CPU data), или другими хитростями, чтобы гарантировать безопасное параллельное выполнение отложенных прерываний на разных процессорах.

Если отложенные операции требуют выполнения в контексте процесса, то из трех возможных вариантов остается единственный выбор — это очереди действий.

Если выполнение в контексте процесса не является обязательным, в частности, если нет необходимости переходить в состояние ожидания (sleep), то использование от ложенных прерываний или тасклетов, скорее всего, подойдет больше. Очереди дей ствий вносят наибольшие накладные расходы, так как они используют потоки ядра и, соответственно, переключение контекста. Нельзя сказать, что они не эффектив ны, но в свете тех тысяч прерываний в секунду, что сетевая подсистема может обе спечить, использование других механизмов может иметь больший смысл. Хотя для большинства ситуаций очередей действий также бывает достаточно.

В плане простоты использования пальму первенства получают очереди дей ствий. Использование очереди events, которая существует по умолчанию, — это про сто детская игра. Далее идут тасклеты, которые тоже имеют простой интерфейс.

Последними стоят отложенные прерывания, которые должны быть определены ста тически.

В табл. 7.3 приведено сравнение различных механизмов обработки нижних по ловин.

Таблица 7.3. Сравнение механизмов обработки нижних половин Механизм обработки нижних половин Контекст выполнения Сериализация Отложенные прерывания (softirq) Прерывание Отсутствует Тасклеты (tasklet) Прерывание По отношению к тасклету такого же типа Очереди отложенных действий Процесс Отсутствует (планируется на вы (work queue) полнение как контекст процесса) 158 Глава Если коротко, то разработчики обычных драйверов имеют всего два варианта выбора. Необходимо ли использовать возможности планировщика, чтобы выпол нять отложенные действия, т.е. необходимо ли переходить в состояние ожидания по какой-либо причине? Если да, то единственный вариант — очереди отложенных действий. В противном случае предпочтительно использовать тасклеты. Только если важна масштабируемость, то стоит обратиться к отложенным прерываниям.

Блокировки между обработчиками нижних половин Мы еще не касались вопросов, связанных с блокировками. Этой теме посвящены следующие две главы. Тем не менее очень важно понимать, что решающим момен том при обработке нижних половин является защита данных общего доступа от кон курентных изменений, даже на однопроцессорной машине. Следует помнить, что об работчик нижней половины прерывания потенциально может выполняться в любой момент времени. Может потребоваться вернуться к текущему разделу, после прочте ния следующих двух глав, если вы далеки от вопросов, связанных с блокировками.

Одно из преимуществ использования тасклетов состоит в том, что они всегда вы полняются последовательно по отношению к себе: один и тот же такслет никогда не будет выполняться параллельно себе даже на двух разных процессорах. Это означа ет, что нет необходимости заботиться о проблемах, связанных с конкурентным вы полнением тасклетов одного типа. Конкурентное выполнение тасклетов нескольких разных типов (в случае, если они совместно используют одни данные) требует при менения блокировок.

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

Если из контекста процесса необходимо обращаться к данным, которые исполь зуются как контекстом процесса, так и обработчиком нижней половины, то необхо димо запретить обработку нижних половин и захватить блокировку перед тем, как начинать работу с данными. Это позволяет гарантировать защиту совместно исполь зуемых данных как на локальном процессоре, так и на разных процессорах SMP си стемы, а также предотвратить взаимоблокировки.

Если имеются данные, которые могут совместно использоваться в контексте пре рывания и в обработчике нижней половины, то необходимо запретить прерывания и захватить блокировку перед тем, как обращаться к этим данным. Именно эти две операции позволяют предотвратить взаимоблокировку и обеспечить защиту для SMP-систем.

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

В главе 8 будут рассмотрены хитрости, связанные с блокировками. В главе 9 будут описаны базовые элементы ядра, которые позволяют осуществлять блокировки.

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

Запрещение обработки нижних половин Обычно только одного запрещения обработки нижних половин недостаточно.

Наиболее часто, чтобы полностью защитить совместно используемые данные, необ ходимо захватить блокировку и запретить обработку нижних половин. Методы, ко торые позволяют это сделать и которые обычно используются при разработке драй веров, будут рассмотрены в главе 9. Однако при разработке самого кода ядра иногда необходимо запретить только обработку нижних половин.

Для того чтобы запретить обработку всех типов нижних половин (всех отло женных прерываний и, соответственно, тасклетов), необходимо вызвать функцию local_bh_disable (). Для разрешения обработки нижних половин необходимо вы звать функцию local_bh_enable (). Да, у этих функций "неправильные" названия.

Никто не потрудился переименовать эти функции, когда интерфейс ВН уступил ме сто интерфейсу отложенных прерываний. В табл. 7.4 приведены сведения об этих функциях.

Таблица 7.4. Список функций управления обработкой нижних половин Функция Описание voi d local_bh_disable () Запретить обработку всех отложенных прерываний (softirq) и тасклетов (tasklet) на локальном процессоре void local_bh_enable () Разрешить обработку всех отложенных прерываний (softirq) и тасклетов (tasklet) на локальном процессоре Вызовы этих функций могут быть вложенными — при этом только последний вы зов функции local_bh_enable () разрешает обработку нижних половин. Например, при первом вызове функции local_bh_disable () запрещается выполнение отло женных прерываний на текущем процессоре. Если функция local_bh_disable () вызывается еще три раза, то выполнение отложенных прерываний будет запрещено.

Их выполнение не будет разрешено до тех пор, пока функция local_bh_enable () не будет вызвана четыре раза.

Такая функциональность реализована с помощью счетчика preerapt_count, кото рый поддерживается для каждого задания (интересно, что этот же счетчик исполь зуется и для вытеснения процессов в режиме ядра)11. Когда значение этого счетчика достигает нуля, то можно начать обработку нижних половин. Так как при вызове функции local_bh_enable () обработка нижних половин запрещена, то эта функ ция также проверяет наличие ожидающих на обработку нижних половин и выпол няет их.

На самом деле этот счетчик используется как системой обработки прерываний, так и системой обработки нижних половин. Наличие одного счетчика для задания позволяет в операционной сис теме Linux реализоиать атомарность заданий. Как показала практика, такой подход очень полезен для нахождения ошибок, например, связанных с тем, что задание переходит в состояние ожида ния в то время, когда выполняет атомарные операции (sleeping-while-atomic bug).

160 Глава Для каждой поддерживаемой аппаратной платформы имеются спои функ ции, которые обычно реализуются через сложные макросы, описанные в файле. Для любопытных ниже приведены соответствующие реализации на языке программирования С.

/* * запрещение обработки нижних половин путем увеличения значения счетчика preempt_count */ void local_bh_disable(void) { struct thread_info *t = current_thread_info()

;

t->preempt_count += SOFTIRQ_OFFSET

;

} /* * уменьшение значения счетчика preempt_count "автоматически" разрешает * обработку нижних половин, если значение счетчика равно нулю * * опционально запускает все обработчики нижних половин, которые ожидают на обработку */ void local_bh_enable(void) { struct thread_info *t = current_thread_info()

;

t->preempt_count -= SOFTIRQ_OFFSET

;

/* * равно ли значение переменной preempt_count нулю и ожидают ли на обработку какие-либо обработчики нижних половин?

* если да, то запустить их / if (unlikely(!t->preempt_count && softirq_pending (smp_processor_id()))) do_softirq()

;

} Эти функции не запрещают выполнения очередей действий. Так как очереди дей ствий выполняются в контексте процесса, нет никаких проблем с асинхронным вы полнением и нет необходимости запрещать их. Поскольку отложенные прерывания и тасклеты могут "возникать" асинхронно (например, при возвращении из обработ чика аппаратного прерывания), то ядру может потребоваться запрещать их. В слу чае использования очередей отложенных действий защита совместно используемых данных осуществляется так же, как и при работе в контексте процесса. Детали рас смотрены в главах 8 и 9.

Обработка нижних половин и отложенные действия Внизу обработки нижних половин В этой главе были рассмотрены три механизма, которые используются для ре ализации отложенных действий в ядре Linux, — отложенные прерывания (softirq), тасклеты (tasklet) и очереди отложенных действий (work queue). Было показано, как эти механизмы работают и как они реализованы. Также обсуждались основные мо менты, связанные с использованием этих механизмов в собственном программном коде, и было показано, какие у них неподходящие названия. Для того чтобы вос становить историческую справедливость, мы также рассмотрели те механизмы об работки нижних половин, которые существовали в предыдущих версиях ядра Linux:

механизмы ВН и task queue.

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

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

162 Глава Введение в синхронизацию выполнения кода ядра приложениях, рассчитанных на работу с совместно используемой памятью (shared memory), необходимо позаботиться о том, чтобы совместно исполь В зуемые ресурсы были защищены от конкурентного доступа. Ядро — не исключение.

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

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

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

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

времени. Начиная с серии ядер 2.6 ядро операционной системы Linux является пре емптивным (вытесняемым). Это подразумевает, что (при отсутствии необходимой защиты) планировщик может вытеснить код ядра в любой момент времени и запу стить на выполнение другое задание. Сегодня есть много сценариев, благодаря кото рым может возникнуть конкурентный доступ к данным в ядре, и все эти варианты требуют защиты данных.

В этой главе рассматриваются проблемы, связанные с параллельным выпол нением кода и синхронизацией выполнения кода в ядре операционной системы.

В следующей главе детально рассмотрены механизмы и интерфейсы, которые предо ставляет ядро операционной системы Linux для решения проблем синхронизации и предотвращения состояния конкуренции за ресурс (race condition, состояние "гонок").

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

Зачем нужна защита Для лучшего понимания того, к чему может привести состояние конкуренции, да вайте рассмотрим примеры повсеместно встречающихся критических участков.

В качестве первого примера рассмотрим ситуацию из реальной жизни

;

банкомат (который еще называют ATM, Automated Teller Machine, или кэш-машиной).

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

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

int total = get_total_from_account()

;

/ *общее количество денег на счету*/ int withdrawal = get_withdrawal_amount()

;

/* количество денег, которые хотят снять */ /* проверить, есть ли у пользователя деньги на счету */ if (total < withdrawal) error("У Вас нет таких денег!") /* Да, у пользователя достаточно денег: вычесть снимаемую сумму из общего количества денег на счету */ total -= withdrawal

;

update_total_funds(total)

;

/* Выдать пользователю деньги */ spit_out_money(withdrawal)

;

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

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

Теперь рассмотрим некоторые численные значения. Допустим, что первая снимае мая сумма равна $100, а вторая — $10, например, за то, что пользователь зашел в банк (что не приветствуется: необходимо использовать банкомат, так как в банках людей не хотят видеть). Допустим также, что у пользователя на счету есть сумма, равная $105. Очевидно, что одна из этих двух транзакций не может завершиться успешно без получения минусов на счету.

Можно ожидать, что получится что-нибудь вроде следующего: первой завершит ся транзакция по снятию платы за вход в банк. Десять долларов — это меньше чем $105, поэтому, если от $105 отнять $10, на счету останется $95, а $10 заработает банк.

Далее начнет пыполняться снятие денег через банкомат, но оно завершится неудач но, так как $95 — это меньше чем $100.

Тем не менее жизнь может оказаться значительно интереснее, чем ожидалось.

Допустим, что две указанные выше транзакции начинаются почти в один и тот же момент времени. Обе транзакции убеждаются, что на счету достаточно денег: $105 — это больше $100 и больше $10. После этого процесс снятия денег с банкомата вычтет $100 из $105 и получится $5. В это же время процесс снятия платы за вход сделает то же самое и вычтет $10 из $105, и получится $95. Далее процесс снятия денег об новит состояние счета пользователя: на счету окажется сумма $5. В конце транзак ция снятия платы за вход также обновит состояние счета, и на счету окажется $95.

Получаем деньги в подарок!

Введение в синхронизацию выполнения кода ядра Ясно, что финансовые учреждения считают своим долгом гарантировать, чтобы такой ситуации не могло возникнуть никогда. Необходимо блокировать счет во вре мя выполнения некоторых операций, чтобы гарантировать атомарность транзакций по отношению к другим транзакциям. Такие транзакции должны полностью выпол няться не прерываясь или не выполняться совсем.

Общая переменная Теперь рассмотрим пример, связанный с компьютерами. Пусть у нас есть очень простой совместно используемый ресурс: одна глобальная целочисленная перемен ная и очень простой критический участок — операция инкремента значения этой переменной:

i++ Это выражение можно перевести в инструкции процессора следующим образом.

Загрузить текущее значение переменной i из памяти в регистр.

Добавить единицу к значению, которое находится в регистре.

Записать новое значение переменной i обратно в память.

Теперь предположим, что есть два потока, которые одновременно выполняют этот критический участок, и начальное значение переменной i равно 7. Результат выполнения будет примерно следующим (каждая строка соответствует одному интер валу времени ).

Поток 1 Поток получить значение i из памяти (7) увеличить i на 1 <7->8) записать значение i в память (8) получить значение i из памяти (8) увеличить i на 1 (8->9) записать значение i в память (9) Как и ожидалось, значение переменной ±, равное 7, было увеличено на единицу два раза и стало равно 9. Однако возможен и другой вариант.

Поток 1 Поток получить значение i из памяти (7) получить значение i из памяти (7) увеличить i на 1 (7->8) увеличить i на 1 (7->8) записать значение i в память (8) записать значение i в память (8) Если оба потока выполнения прочитают первоначальное значение переменной i перед тем, как оно было увеличено на 1, то оба потока увеличат его на единицу и запишут в память одно и то же значение. В результате переменная i будет содержать значение 8, тогда как она должна содержать значение 9. Это один из самых простых примеров критических участков. К счастью, решение этой проблемы простое — необ ходимо просто обеспечить возможность выполнения всех рассмотренных операций за один неделимый шаг. Для большинства процессоров есть машинная инструкция, которая позволяет атомарно считать данные из памяти, увеличить их значение на 166 Глава и записать обратно в память, выделенную для переменной. Использование такой ин струкции позволяет решить проблему. Возможно только два варианта правильного выполнения этого кода — следующий.

Поток 1 Поток 2 \ увеличить i на 1 (7->8) увеличить i на 1 (8->9) Или таким образом.

Поток 1 Поток увеличить i на 1 (7->8) увеличить i на 1 (8->9) Две атомарные операции никогда не могут перекрываться. Процессор на физи ческом уровне гарантирует это. Использование такой инструкции решает проблему.

Ядро предоставляет несколько интерфейсов, которые позволяют реализовать ато марные операции. Эти интерфейсы будут рассмотрены в следующей главе.

Блокировки Теперь давайте рассмотрим более сложный пример конкуренции за ресурсы, ко торый требует более сложного решения. Допустим, что у нас есть очередь запросов, которые должны быть обработаны. Как реализована очередь — не существенно, но мы будем считать, что это — связанный список, в котором каждый узел соответствует одному запросу. Очередью управляют две функции: одна— добавляет новый запрос в конец очереди, а другая — извлекает запрос из головы очереди и делает с ним не что полезное. Различные части ядра вызывают обе эти функции, поэтому запросы могут постоянно поступать, удаляться и обрабатываться. Все манипуляции очередью запросов, конечно, требуют нескольких инструкций. Если один из потоков пытается считывать данные из очереди, а другой поток находится в средине процесса манипу ляции очередью, то считывающий поток обнаружит, что очередь находится в несо гласованном состоянии. Легко понять, что при конкурентном обращении к очереди может произойти разрушение структуры данных. Часто ресурс общего доступа — это сложная структура данных, и в результате состояния конкуренции возникает разру шение этой структуры.

Вначале кажется, что описанная ситуация не имеет простого решения. Как можно предотвратить чтение очереди на одном процессоре в тот момент, когда другой про цессор обновляет ее? Вполне логично аппаратно реализовать простые инструкции, такие как атомарные арифметические операции или операции сравнения, тем не менее было бы смешно аппаратно реализовывать критические участки неопределен ного размера, как в приведенном примере. Все что нужно — это предоставить метод, который позволяет отметить начало и конец

;

критического участка, и предотвратить или заблокировать (lock) доступ к этому участку, пока другой поток выполняет его.

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

В приведенном выше примере очереди запросов для защиты очереди может ис пользоваться одна блокировка. Как только необходимо добавить запрос в очередь, поток должен вначале захватить блокировку. Затем он может безопасно добавить запрос в очередь и после этого освободить блокировку. Если потоку необходимо извлечь запрос из очереди, он тоже должен захватить блокировку. После этого он может прочитать запрос и удалить его из очереди. В конце поток освобождает блокировку. Любому другому потоку для доступа к очереди также необходимо ана логичным образом захватывать блокировку. Так как захваченная блокировка может удерживаться только одним потоком в любой момент времени, то только один поток может производить манипуляции с очередью в любой момент времени. Блокировка позволяет предотвратить конкуренцию и защитить очередь от состояния конкурен ции за ресурс.

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

Поток 1 Поток Попытаться заблокировать очередь Попытаться заблокировать очередь успешно: блокировка захвачена неудачно: ожидаем...

ожидаем...

обратиться к очереди... ожидаем...

разблокировать очередь успешно: блокировка захвачена обратиться к очереди.,.

разблокировать очередь...

Заметим, что блокировки бывают необязательными (рекомендуемыми, advisory) и обязательными (навязываемыми, voluntary). Блокировки— это чисто программные конструкции, преимуществами которых должны пользоваться программисты. Никто не запрещает писать код, который манипулирует нашей воображаемой очередью без использования блокировок. Однако такая практика в конечном итоге приведет к со стоянию конкуренции за ресурс и разрушению данных.

Блокировки бывают различных "форм" и "размеров". В операционной системе Linux реализовано несколько различных механизмов блокировок. Наиболее суще ственная разница между ними — это поведение кода в условиях, когда блокировка захватываетя (конфликт при захвате блокировки, contended lock). Для некоторых типов блокировок, задания просто ожидают освобождения блокировки, постоянно выполняя проверку освобождения в замкнутом цикле (busy wait2), в то время как дру гие тины блокировок переводят задание в состояние ожидания до тех пор, пока бло кировка не освободится.

Иными словами, "вращаются" (spin) в замкнутом цикле, ожидая на освобождение блокировки.

168 Глава В следующей главе рассказывается о том, как ведут себя различные типы блоки ровок в операционной системе Linux, и об интерфейсах взаимодействия с этими блокировками.

Проницательный читатель в этом месте должен воскликнуть: "Блокировки не ре шают проблемы, они просто сужают набор всех возможных критических участков до кода захвата и освобождения блокировок. Тем не менее, здесь потенциально может возникать состояние конкуренции за ресурсы, хотя и с меньшими последствиями!" К счастью, блокировки реализованы на основе атомарных операций, которые гаран тируют, что состояние конкуренции за ресурсы не возникнет. С помощью одной ма шинной инструкции выполняется проверка захвачен ли ключ, и, если нет, то этот ключ захватывается. То, как это делается, очень сильно зависит от аппаратной плат формы, но почти для всех процессоров определяется машинная инструкция test-and set (проверить и установить), которая позволяет проверить значение целочисленной переменной и присвоить этой переменной указанное число, если се значение равно нулю. Значение нуль соответствует незахваченной блокировке.

Откуда берется параллелизм При работе в пространстве пользователя необходимость синхронизации возни кает из того факта, что программы выполняются преемптивно, т.е. могут быть вы теснены другой программой по воле планировщика. Поскольку процесс может быть вытеснен в любой момент и другой процесс может быть запущен планировщиком для выполнения на этом же процессоре, появляется возможность того, что процесс может быть вытеснен независящим от него образом во время выполнения критиче ского участка. Если новый, запланированный на выполнение процесс входит в тот же критический участок (скажем, если оба процесса — потоки одной программы, ко торые могут обращаться к общей памяти), то может возникнуть состояние конкурен ции за ресурс. Аналогичная проблема может возникнуть даже в однопоточной про грамме при использовании сигналов, так как сигналы приходят асинхронно. Такой тип параллелизма, когда два события происходят не одновременно, а накладываются друг на друга, так вроде они происходят в один момент времени, называется псевдо параллелизмом (pseudo-concurrency).

На машине с симметричной многопроцессорностью два процесса могут действи тельно выполнять критические участки в один и тот же момент времени. Это назы вается истинным, параллелизмом (true concurrency). Хотя причины и семантика истин ного и псевдопараллелизма разные, они могут приводить к совершенно одинаковым состояниям конкуренции и требуют аналогичных средств защиты. В ядре причины параллельного выполнения кода следующие.

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

• Отлаженные прерывания и тасклеты. Ядро может выполнять обработчики softirq и тасклеты практически в любой момент времени и прерывать код, который выполняется в данный момент времени.

• Преемптивностъ ядра. Так как ядро является вытесняемым, то одно задание, ко торое работает в режиме ядра, может вытеснить другое задание, тоже работа ющее в пространстве ядра.

Введение в синхронизацию выполнения кода ядра • Переход в состояние ожидания и синхронизация с пространством пользователя.

Задание, работающее в пространстве ядра, может переходить в состояние ожида ния, что вызывает активизацию планировщика и выполнение нового процесса.

• Симметричная многопроцессорность. Два или больше процессоров могут выпол нять код в один и тот же момент времени.

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

И наконец, два процессора никогда не должны одновременно обращаться к совмест но используемым данным. Когда ясно, какие данные требуют защиты, то уже нетруд но применить соответствующие блокировки, чтобы обеспечить всем безопасность.

Сложнее идентифицировать возможные условия возникновения таких ситуаций и определить, что для предотвращения конкуренции необходима та или иная форма защиты. Давайте еще раз пройдем через этот момент, потому что он очень важен.

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

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

Код, который безопасно выполнять параллельно с обработчиком прерывания, на зывается безопасным при прерываниях (iterrupt-safe). Код, который содержит защиту от конкурентного доступа к ресурсам при симметричной многопроцессорной обра ботке, называется безопасным при SMP-обработке (SMP-safe). Код, который имеет за щиту от конкурентного доступа к ресурсам при вытеснении кода ядра, называется безопасным при вытеснения3 (preempt-safe). Механизмы, которые во всех этих случаях используются для обеспечения синхронизации и защиты от состояний конкуренции, будут рассмотрены в следующей главе.

Что требует защиты Жизненно важно определить, какие данные требуют защиты. Так как любой код, который может выполняться параллельно, может потребовать защиты. Вероятно, легче определить, какие данные не требуют защиты, и работать дальше, отталкива ясь от этого. Очевидно, что все данные, которые доступны только одному потоку выполнения, не требуют защиты, поскольку только этот поток может обращаться к Дальше будет показано, что, за некоторыми исключениями, код, который безопасен при SMP-об работке, также безопасен и при вытеснениях.

170 Глава этим данным. Например, локальные переменные, которые выделяются в автомати ческой памяти (и те, которые находятся в динамически выделяемой памяти, если их адреса хранятся только в стеке), не требуют никаких блокировок, так как они су ществуют только в стеке выполняющегося потока. Точно так же данные, к которым обращается только одно задание, не требуют применения блокировок (так как один поток может выполняться только на одном процессоре в любой момент времени).

Что же тогда требует применения блокировок? Это — большинство глобальных структур данных ядра. Есть хорошее эмпирическое правило: если, кроме одного, еще и другой поток может обращаться к данным, то эти данные требуют примене ния какого-либо типа блокировок. Если что-то видно кому-то еще — блокируйте его.

Помните, что блокировать необходимо данные, а не код.

Параметры КОНФИГУРАЦИИ ядра: SMP или UP Так как ядро операционной системы Linux может быть сконфигурировано на этапе компиляции, имеет смысл "подогнать" ядро под данный тип машины. Важной функцией ядра является под держка симметричной многопроцессорной обработки (SMP), которая включается с помощью параметра конфигурации ядра CONFI G_SMP. На однопроцессорной {uniprocessor, UP) маши не исчезают многие проблемы, связанные с блокировками, и, следовательно, если параметр CONFIG_SMP не установлен, то код, в котором нет необходимости, не компилируется в испол няемый образ ядра. Например, это позволяет на однопроцессорной машине отказаться от на кладных расходов, связанных со спин-блокировками. Аналогичный прием используется для па раметра CONFIG_PREEMPT (параметр ядра, который указывает, будет ли ядро вытесняемым).

Такое решение является отличным проектным решение, поскольку позволяет использовать общий четкий исходный код, а различные механизмы блокировок используются при необхо димости. Различные комбинации параметров CONFI G_SMP И CONFIG_PREEMPT на различных аппаратных платформах позволяют компилировать в ядро различные механизмы блокировок.

При написании кода необходимо обеспечить все возможные варианты защиты для всех воз можных случаев жизни и всех возможных сценариев, которые будут рассмотрены.

При написании кода ядра следует задать себе следующие вопросы.

• Являются ли данные глобальными? Может ли другой поток выполнения, кроме текущего, обращаться к этим данным?

• Являются ли данные совместно используемыми из контекста процесса и из контекста прерывания? Используют ли их совместно два обработчика преры ваний?

• Если процесс во время доступа к данным будет вытеснен, может ли новый про цесс, который запланирован на выполнение, обращаться к этим же данным?

• Может ли текущий процесс перейти в состояние ожидания (заблокироваться) на какой-либо операции? Если да, то в каком состоянии он оставляет все со вместно используемые данные?

• Что запрещает освободить память, в которой находятся данные?

• Что произойдет, если эта же функция будет вызвана на другом процессоре?

• Как все это учесть?

Если коротко, то почти все глобальные данные требуют применения тех или дру гих методов синхронизации, которые будут рассмотрены в следующей главе.

Введение в синхронизацию выполнения кода ядра Взаимоблокировки Взаимоблокировка (тупиковая ситуация, deadlock) — это состояние, при котором каждый поток ожидает на освобождение одного из ресурсов, а все ресурсы при этом захвачены. Потоки будут ожидать друг друга, и они никогда не смогут освободить захваченные ресурсы. Поэтому ни один из потоков не сможет продолжать выполне ние, что означает наличие взаимоблокировки.

Хорошая аналогия— это перекресток, на котором стоят четыре машины, кото рые подъехали с четырех разных сторон. Каждая машина ожидает, пока не уедут остальные машины, и ни одна из машин не сможет уехать

;

в результате получается тупиковая ситуация.

Самый простой пример взаимоблокировки— это самоблокировка4 (self-deadlock).

Если поток выполнения пытается захватить ту блокировку, которую он уже удержи вает, то ему необходимо дождаться, пока блокировка не будет освобождена. Но по ток никогда не освободит блокировку, потому что он ожидает на ее захват, и это приводит к тупиковой ситуации.

захватить блокировку захватить блокировку еще раз ждать, пока блокировка не будет освобождена...

Аналогично рассмотрим n потоков и n блокировок. Если каждый поток удержива ет блокировку, на которую ожидает другой поток, то все потоки будут заблокированы до тех пор, пока не освободятся те блокировки, на освобождение которых ожидают потоки. Наиболее часто встречающийся пример — это два потока и две блокировки, что часто называется взаимоблокировка типа ABBA (ABBA deadlock).

Поток 1 Поток захватить блокировку А захватить блокировку В попытка захватить блокировку В попытка захватить блокировку А ожидание освобождения блокировки В ожидание освобождения блокировки А Оба потока будут ожидать друг друга, и ни один из потоков никогда не освободит первоначально захваченной блокировки, поэтому ни одна из блокировок не будет освобождена. Такая тупиковая ситуация еще называется deadly embrace (буквально.

смертельные объятия).

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

• Жизненно важным является порядок захвата блокировок. Вложенные блокиров ки всегда должны захватываться в одном и том же порядке. Это предотвращает взаимоблокировку нескольких потоков (deadly embrace). Порядок захвата блоки ровок необходимо документировать, чтобы другие тоже могли его соблюдать.

Б некоторых ядрах такой тип тупиковой ситуации предотвращается с помощью рекурсивных бло кировок, которые позволяют одному потоку выполнения захватывать блокировку несколько раз.

В операционной системе Linux, к счастью, таких блокировок нет. И это считается хорошим то ном. Хотя рекурсивные блокировки позволяют избежать проблемы самоблокировок, они приводят к небрежному использованию блокировок.

172 Глава • Необходимо предотвращать зависания. Следует спросить себя: "Всегда ли этот код сможет завершиться'?'''. Если не выполнится какое-либо условие, то не будет ли что-то ожидать вечно?

• Не захватывать одну и ту же блокировку дважды.

• Сложность в схеме блокировок — верный путь к тупиковым ситуациям, поэто му при разработке необходимо стремиться к простоте.

Первый пункт важный и наименее сложный для выполнения. Если две или бо лее блокировок захватываются в одном месте, то они всегда должны захватываться в строго определенном порядке. Допустим, у нас есть три блокировки cat, dog и fox, которые используются для защиты данных с такими же именами. И еще допустим, что у нас есть функция, которая должна работать с этими тремя структурами данных одновременно— например, может копировать данные между ними. Б любом случае, для того чтобы гарантировать безопасность доступа, эти структуры данных необхо димо защищать блокировками. Если одна функция захватывает эти блокировки в следующем порядке: cat, dog и в конце fox, то любая другая функция должна захва тывать эти блокировки (или только некоторые из них) в том же порядке. Например, если захватывать сначала блокировку fox, а потом блокировку dog, то это потен циальная возможность взаимоблокировки (а значит, ошибки в работе), потому что блокировка dog всегда должна захватываться перед блокировкой fox. И еще раз рас смотрим пример, как может возникнуть взаимоблокировка.

Поток 1 Поток захватить блокировку cat захватить блокировку fox захватить блокировку dog попытка захватить блокировку dog попытка захватить блокировку fox ожидание освобождения блокировки dog ожидание освобождения блокировки fox — Поток 1 ожидает освобождения блокировки fox, которую удерживает поток 2, а поток 2 в это время ожидает освобождения блокировки dog, которую удерживает поток 1. Ни один из потоков никогда не освободит своих блокировок, и, соответ ственно, оба потока будут ждать вечно — возникает тупиковая ситуация. Если оба по тока всегда захватывают блокировки в одном и том же порядке, то подобной тупико вой ситуации возникнуть не может.

Если несколько процедур захвата блокировок вложены друг в друга, то должен быть принят определенный порядок захвата. Хорошая практика — всегда использо вать комментарий сразу перед объявлением блокировки, который указывает на по рядок захвата. Использовать что-нибудь вроде следующего будет хорошей идеей.

/* * cat_lock - всегда захватывать перед блокировкой dog * (и всегда захватывать блокировку dog перед блокировкой fox) */ Следует заметить, что порядок освобождения блокировок не влияет на возможность появления взаимоблокировок, хотя освобождать блокировки в обратном порядке по отношению к их захвату — это хорошая привычка.

Очень важно предотвращать взаимоблокировки. В ядре Linux есть некоторые от ладочные возможности, которые позволяют обнаруживать взаимоблокировки при выполнении кода ядра. Эти возможности будут рассмотрены в следующем разделе.

Введение в синхронизацию выполнения кода ядра Конфликт при захвате блокировки и масштабируемость Термин "конфликт при захвате блокировки" (lock contention, или просто contention) используется для описания блокировки, которая в данный момент захвачена и на освобождение которой ожидают другие потоки. Блокировки с высоким уровнем кон фликтов (highly contended) — это те, на освобождение которых всегда ожидает много потоков. Так как задача блокировок — это сериализация доступа к ресурсу, то не вы зовет большого удивления тот факт, что блокировки снижают производительность системы. Блокировка с высоким уровнем конфликтов может стать узким местом в системе, быстро уменьшая производительность. Конечно, блокировки необходимы для того, чтобы предотвратить "развал" системы, поэтому решение проблемы высо кого уровня конфликтов при блокировках также должно обеспечивать необходимую защиту от состояний конкуренции за ресурсы.

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

Масштабируемость операционной системы Linux на большее количество про цессоров возросла поразительным образом с того времени, когда поддержка много процессорной обработки была встроена в ядра серии 2.0. В те дни, когда поддержка многопроцессорности в операционной системе Linux только появилась, лишь одно задание могло выполняться в режиме ядра в любой момент времени. В ядрах серии 2.2 это ограничение было снято, так как механизмы блокировок стали более мелко структурными. В серии 2.4 и выше блокировки стали еще более мелкоструктурными.

Сегодня в ядрах серии 2.6 блокировки имеют очень мелкую гранулярность, а мас штабируемость получается очень хорошей.

Структурность (гранулярность, granularity) блокировки— это описание объемов тех данных, которые защищаются блокировкой, например все структуры данных одной подсистемы. С другой стороны, блокировка на уровне очень мелких структур ных единиц (fine grained), используется для защиты очень маленького объема дан ных, например одного поля структуры. В реальных ситуациях большинство блоки ровок попадают между этими крайностями, они используются не для защиты целой подсистемы, но и не для защиты одного поля, а возможно для защиты отдельного экземпляра структуры. Большинство блокировок начинали использоваться на уровне крупных структурных единиц (cource graine), а потом их стали разделять на более мелкие структурные уровни, как только конфликты при захвате этих блокировок становились проблемой.

Один из примеров перевода блокировок на более мелкий структурный уровень — это блокировки очередей выполнения планировщика (runqueue), которые рассмо трены в главе 4, "Планирование выполнения процессов". В ядрах серии 2.4 и более ранних планировщик имел всего одну очередь выполнения (вспомним, что очередь 174 Глава выполнения— это список готовых к выполнению процессов). В серии 2.6 был пред ложен О(1)-планировтцик, в котором для каждого процессора используется своя очередь пыполнения, каждая очередь имеет свою блокировку. Соответствующие бло кировки развились из одной глобальной блокировки в несколько отдельных блоки ровок для каждой очереди, а использование блокировок развилось из глобального блокирования в использование блокировок на отдельных процессорах. Эта оптими зация очень существенна, так как на больших машинах блокировка очереди выпол нения имеет очень высокий уровень конфликтов при захвате, что приводит к сери ализации планирования выполнения процессов. Иными словами, код планировщика выполнял только один процессор системы в любой момент времени, а остальные процессоры — ждали.

В общем такое повышение масштабируемости — это очень хорошая вещь, которая позволяет повысить производительность операционной системы Linux на больших и более мощных системах. Чрезмерное увлечение "ростом" масштабируемости мо жет привести к снижению производительности на небольших многопроцессорных и однопроцессорных машинах, потому что для небольших машин не требуются такие мелкоструктурные блокировки, а им приходится иметь дело с большей сложностью и с большими накладными расходами. Рассмотрим связанный список. Первоначальная схема блокировки обеспечивает одну блокировку на весь список. Со временем эта одна блокировка может стать узким местом на очень большой многопроцессорной машине, на которой очень часто обращаются к связанному списку. Для решения про блемы одна блокировка может быть разбита на большое количество блокировок — одна блокировка на один элемент списка. Для каждого элемента списка, который необходимо прочитать или записать, необходимо захватывать уникальную блокиров ку этого элемента. Теперь конфликт при захвате блокировки будет только в случае, когда несколько процессоров обращаются к одному элементу списка. Что делать, если все равно есть высокий уровень конфликтов? Может быть, необходимо исполь зовать блокировку для каждого поля элемента списка? (Ответ: НЕТ.) Если серьезно, даже когда очень мелко структурированные блокировки хорошо работают на очень больших SMP-машинах, то как они будут работать на двухпроцессорных машинах?

Накладные расходы, связанные с дополнительными блокировками, будут напрасны ми, если на двухпроцессорной машине нет существенных конфликтов при работе с блокировками.

Тем не менее масштабируемость— это важный фактор. Важно с самого нача ла разрабатывать схему блокировок для обеспечения хорошей масштабируемости.

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

Необходимо начинать с простого и переходить к сложному только при необ ходимости. Простота — это ключевой момент.

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

Обеспечение достаточной защиты для любого случая — SMP, вытеснение кода ядра и так далее — в результате приведет к гарантии того, что все данные будут за щищены на любой машине и в любой конфигуратщи. В следующей главе будет рас сказано о том, как это осуществить.

Теперь, когда мы хорошо подкованы в теории параллелизма, синхронизации и блокировок, давайте углубимся в то, какие существуют конкретные инструменты, предоставляемые ядром Linux, для того чтобы гарантировать отсутствие состояний конкуренции и тупиковых ситуаций в коде.

176 Глава Средства синхронизации в ядре предыдущей главе обсуждались источники и решения проблем, связанных с конкуренцией за ресурсы. К счастью, в ядре Linux реализовано большое семей В ство средств синхронизации. В этой главе обсуждаются эти средства, интерфейсы к ним, а также особенности их работы и использования. Эти решения позволяют раз работчикам писать код, в котором отсутствуют состояния конкуренции за ресурсы.

Атомарные операции Атомарные операции (atomic operations) предоставляют инструкции, которые выполняются атомарно, — т.е. не прерываясь. Так же как и атом вначале считался неделимой частицей, атомарные операции являются неделимыми инструкциями.

Например, как было показано в предыдущей главе, операция атомарного инкремен та позволяет считывать из памяти и увеличивать на единицу значение переменной за один неделимый и непрерывный шаг. В отличие от состояния конкуренции за ре сурс, которая обсуждалась в предыдущей главе, результат выполнения такой опера ции всегда один и тот же, например, как показано в следующем примере (допустим, что значение переменной i вначале равно 7).

Поток 1 Поток инкремент i (7->8) инкремент i (8->9) Результирующее значение 9— правильное. Параллельное выполнение двух атомар ных операций с одной и той же переменной невозможно никогда. Таким образом, для такой операции инкремента состояние конкуренции за ресурс возникнуть не может.

Ядро предоставляет два набора интерфейсов для выполнения атомарных опе раций: один — для работы с целыми числами, а другой — для работы с отдельными битами. Эти интерфейсы реализованы для всех аппаратных платформ, которые под держиваются операционной системой Linux. Большинство аппаратных платформ поддерживают атомарные операции или непосредственно, или путем блокировки шины доступа к памяти при выполнении одной операции (что в свою очередь га рантирует, что другая операция не может выполниться параллельно). Это как-то по зволяет справиться с проблемой в случае аппаратных платформ, таких как SPARC, которые не поддерживают базовых машинных инструкций для выполнения атомар ных операций.

Целочисленные атомарные операции Средства выполнения атомарных операций с целыми числами работают с типом данных at omi ct. Вместо того, чтобы использовать функции, которые работают непосредственно с типом данных int языка С, по ряду причин используется спе циальный тип данных. Во-первых, функции, которые выполняют атомарные опера ции, принимают только аргументы типа atomict, это гарантирует, что атомарные операции выполняются только с данными этого специального типа. В то же время это также гарантирует, что данные этого типа не смогут передаваться в другие функ ции, которые не выполняют атомарных операций. Действительно, ничего хорошего не будет от таких атомарных операций, которые иногда атомарные, а иногда— нет.

Следующий момент— использование типа atomic_t позволяет гарантировать, что компилятор (по ошибке, но для повышения эффективности) не будет оптимизи ровать операции обращения к атомарным переменным. Важно, чтобы атомарные операции получали правильное значение адреса переменной в памяти, а не адреса временных копий. И наконец, за типом atomi ct скрываются различия между реа лизациями для различных аппаратных платформ.

Кроме того, что тип atomic_t — это 32-разрядное целое число на всех машинах, которые поддерживаются операционной системой Linux, при разработке кода не обходимо учитывать, что максимальный диапазон значений переменной этого типа не может быть больше 24 бит. Это связано с аппаратной платформой SPARC, для которой используется несколько странная реализация атомарных операций: в млад шие 8 бит 32-разрядного целого числа типа int встроена блокировка, как показано па рис. 9.1.

32-разрядный тип atomic_t Блокировка 24-битовое знаковое целое (Бит) 31 7 О Рис. 9.1, Структура 32-битового типа atomic_t для аппа ратной платформы SPARC в старой реализации Блокировка используется для предотвращения параллельного доступа к перемен ной атомарного типа, так как для аппаратной платформы SPARC отсутствует соот ветствующая поддержка на уровне машинных инструкций. Следовательно, на маши нах SPARC могут быть использованы только 24 бит. Хотя код, который рассчитан на использование полного 32-битового диапазона значений, будет работать и на маши нах других типов, он может приводить к странным и коварным ошибкам на машинах типа SPARC, и так делать не нужно. В последнее время умные хакеры додумались, как для аппаратной платформы SPARC обеспечить тип atomic_t, который позволя 178 Глава ет хранить полноценное 32-разрядное целое число, и указанного ограничения боль ше не существует. Тем не менее старая 24-битовая реализация все еще используется в старом коде для аппаратной платформы SPARC, и этот код все еще имеется в файле для этой аппаратной платформы.

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

Объявление переменных типа atomic_t производится обычным образом. При необходимости можно установить заданное значение этой переменной.

. atomic_t u

;

/* определение переменной и */ atomic_t v = ATOMIC_INIT(0)

;

/* определение переменной v и инициализация ее в значение нуль */ Выполнять операции так же просто.

atomic_set(&v, 4)

;

/* v = 4 (атомарно) */ atomic_add(2, &v)

;

/*v = v + 2 = 6 (атомарно) */ atomic_inc(&v)

;

/*v = v+l = 7 (атомарно) */ Если необходимо конвертировать тип atomic_t в тип i nt, то нужно использо вать функцию atomic_read().

printk("%d\n", atomic_read(&v))

;

/* будет напечатано "7" */ Наиболее частое использование атомарных целочисленных операций — это инкремент счетчиков. Защищать один счетчик с помощью сложной системы бло кировок — это глупо, поэтому разработчики используют вызовы atomi c_i nt () и atomic_dec (), которые значительно быстрее. Еще одно использование атомарных целочисленных операций — это атомарное выполнение операции с проверкой ре зультата. Наиболее распространенный пример — это атомарные декремент и про верка результата, с помощью функции int atomic_dec_and_test(atomic_t *v) Эта функция уменьшает на единицу значение заданной переменной атомарного типа. Если результат выполнения операции равен нулю, то возвращается значение true, иначе возвращается false. Полный список всех атомарных операций с целы ми числами (т.е. тех, которые доступны для всех аппаратных платформ) приведен в табл. 9.1. Все операции, которые реализованы для определенной аппаратной плат формы, приведены в файле.

Обычно атомарные операции реализованы как функции с подстановкой тела и встраиваемыми инструкциями на языке ассемблера (разработчики ядра любят i nl i ne). В случае если какая-либо из функций обладает внутренней атомарнос тью, то обычно она выполняется в виде макроса. Например, для большинства нор мальных аппаратных платформ считывание одного машинного слова данных — это атомарная операция. Операция считывания всегда возвращает машинное слово в непротиворечивом состоянии или перед операцией записи, или после нее, но во Средства синхронизации в ядре время операции записи чтение не может быть выполнено никогда.. Следовательно, функция atomic_read() обычно реализуется как макрос, который возвращает цело численное значение переменной типа atomic_t.

Таблица 9.1. Полный список всех атомарных операций с целыми числами Атомарная целочисленная операция Описание ATOMIC_INIT(int i) Объявление и инициализация в значение i переменной типа atomi c_t int atomic_ read(atomic_t *y) Атомарное считывание значения целочислен ной переменной v void atomic_set (atomic_t *v, int i) Атомарно установить переменную v в значение i Атомарно прибавить значение i к переменной v void atomic_add (int i, atomic_t *v) Атомарно вычесть значение 1 из переменной v void atomic_sub(int i, atomic_t *v) Атомарно прибавить единицу к переменной v void atomic_inc(atomic_t *v) Атомарно вычесть единицу из переменной v void atomic_dec(atomic_t *v) Атомарно вычесть значение i из переменной v и возвратить t rue, если результат равен нулю, int atomic_sub_and_test(int i, atomic_t *v) и f al se в противном случае Атомарно прибавить значение i к переменной v и возвратить t rue, если результат операции int atomic_add_negative(int i, atomic_t *v) меньше нуля, иначе возвратить f al se Атомарно вычесть единицу из переменной v и возвратить t rue, если результат операции int atomic_dec_and_test (atomic_t *v) равен нулю, иначе возвратить f al se Атомарно прибавить единицу к переменной v и возвратить t rue, если результат операции int atomic_inc_and_test(atomic_t *v) равен нулю, иначе возвратить f al se Атомарность и порядок выполнения От атомарных операций чтения перейдем к различиям между атомарностью и порядком выпол нения. Как уже рассказывалось, операции чтения одного машинного слова всегда выполняют ся атомарно. Эти операции никогда не перекрываются операциями записи того же машинного слова. Иными словами, операция чтения данных всегда возвращает машинное слово в конси стентном состоянии: иногда возвращается значение, которое было до записи, а иногда— то, которое стало после записи, но никогда не возвращается значение, которое было во время за писи. Например, если целочисленное значение вначале было равно 42, а потом стало 365, то операция чтения всегда вернет значение 42 или 365, но никогда не смешанное значение. Это называется атомарностью.

Иногда бывает так, что вашему коду необходимо нечто большее, например операция чтения всегда выполняется перед ожидающей операцией записи. Это называется не атомарностью, а порядком выполнения (ordering). Атомарность гарантирует, что инструкции выполняются не прерываясь и что они либо выполняются полностью, либо не выполняются совсем. Порядок вы полнения же гарантирует, что две или более инструкций, даже если они выполняются разными потоками или разными процессами, всегда выполняются в нужном порядке.

Атомарные операции, которые обсуждаются в этом разделе, гарантируют только атомарность.

Порядок выполнения гарантируется с помощью операций барьеров (barrier), которые будут рассмотрены дальше в текущей главе.

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

Битовые атомарные операции В дополнение к атомарным операциям с целыми числами, ядро также предостав ляет семейство функций, которые позволяют работать на уровне отдельных битов.

Не удивительно, что эти операции зависят от аппаратной платформы и определены в файле.

Тем не менее может вызвать удивление то, что функции, которые реализуют би товые операции, работают с обычными адресами памяти. Аргументами функций яв ляются указатель и номер бита. Бит 0 — это наименее значащий бит числа, которое находится по указанному адресу. На 32-разрядных машинах бит 31 — это наиболее значащий бит, а бит 0 — наименее значащий бит машинного слова. Нет ограничений на значение номера бита, которое передается в функцию, хотя большинство пользо вателей работают с машинными словами и номерами битов от 0 до 31 (или до 63 для 64-битовых машин).

Так как функции работают с обычными указателями, то в этом случае нет аналога типу atomic_t, который используется для операций с целыми числами. Вместо этого можно использовать указатель на любые данные. Рассмотрим следующий пример.

unsigned long word = 0

;

set_bit(0,&word)

;

/* атомарно устанавливается бит 0 */ set_bit(l, &word)

;

/* атомарно устанавливается бит 1 */ printk("%ul\n", word)

;

/* будет напечатано "З" */ clear_bit(1, &word)

;

/* атомарно очищается бит 1 */ change_bit(0, &word)

;

/* атомарно изменяется значение бита 1, теперь он очищен */ /* атомарно устанавливается бит нуль и возвращается предыдущее значение этого бита (нуль) */ if (test_and_set_bit(0, &word)) { /* условие никогда не выполнится... */ } Список стандартных атомарных битовых операций приведен в табл. 9.2.

Для удобства работы также предоставляются неатомарные версии всех битовых операций. Эти операции работают так же, как и их атомарные аналоги, но они не га рантируют атомарности выполнения операций, и имена этих функций начинаются с двух символов подчеркивания. Например, неатомарная форма функции t est _bi t () будет иметь имя t es t _bi t (). Если нет необходимости в том, чтобы операции были атомарными, например, когда данные уже защищены с помощью блокировки, неатомарные операции могут выполняться быстрее.

Средства синхронизации в ядре Таблица 9.2. Список стандартных атомарных битовых операций Атомарная битовая операция Описание void set_bit (int nr, void *addr) Атомарно установить nr -й бит в области памя ти, которая начинается с адреса addr void clear_bit (int nr, void *addr) Атомарно очистить nr -й бит в области памяти, которая начинается с адреса addr void change_bit (int nr, void *addr) Атомарно изменить значение nr -го бита в обла сти памяти, которая начинается с адреса addr, на инвертированное i nt test_and_set_bi t(i nt nr, void *addr) Атомарно установить значение nr-го бита в обла сти памяти, которая начинается с адреса addr, и возвратить предыдущее значение этого бита int test_and_clear_bit (int nr, void *addr) Атомарно очистить значение nr -го бита в обла сти памяти, которая начинается с адреса addr, и возвратить предыдущее значение этого бита int test_and_change_bit (int nr, void *addr) Атомарно изменить значение nr -го бита в обла сти памяти, которая начинается с адреса addr, на инвертированное и возвратить предыдущее значение этого бита int test_bit (int nr, void *addr) Атомарно возвратить значение nr -го бита в об ласти памяти, которая начинается с адреса addr Откуда берутся неатомарные битовые операции На первый взгляд, такое понятие, как неатомарная битовая операция, вообще не имеет смыс ла. Задействован только один бит, и здесь не может быть никакого нарушения целостности.

Одна из операций всегда завершится успешно, что еще нужно? Да, порядок выполнения может быть важным, но атомарность-то тут при чем? В конце концов, если значение бита равно тому, которое устанавливается хотя бы одной из операций, то все хорошо, не так ли?

Давайте вспомним, что такое атомарность? Атомарность означает, что операция или заверша ется полностью, не прерываясь, или не выполняется вообще. Следовательно, если выполня ется две атомарные битовые операции, то предполагается, что они обе должны выполниться.

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

Более того, если другие битовые операции тоже выполняются успешно, то в некоторые мо менты времени значение бита должно соответствовать тому, которое устанавливается этими промежуточными операциями.

Допустим, выполняются две атомарные битовые операции: первоначальная установка бита, а затем очистка бита. Без атомарности этот бит может быть очищен, но никогда не установлен.

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

Иногда может требоваться именно такое поведение, особенно если критичен порядок вы полнения.

182 Глава Ядро также предоставляет функции, которые позволяют найти номер первого установленного (или не установленного) бита, в области памяти, которая начинает ся с адреса addr:

int find_first_bit(unsigned long *addr, unsigned int size) int find_first_zero_bit(unsigned long *addr, unsigned int size) Обе функции в качестве первого аргумента принимают указатель на область па мяти и в качестве второго аргумента — количество битов, по которым будет произ водиться поиск. Эти функции возвращают номер первого установленного или не установленного бита соответственно. Если код производит поиск в одном машинном слове, то оптимальным решением будет использовать функции f f s() и _ffz(), которые в качестве единственного параметра принимают машинное слово, где будет производиться поиск.

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

Спин-блокировки Было бы очень хорошо, если бы все критические участки были такие же простые, как инкремент или декремент переменной, однако в жизни все более серьезно. В ре альной жизни критические участки могут включать в себя несколько вызовов функ ций. Например, очень часто данные необходимо извлечь из одной структуры, затем отформатировать, произвести анализ этих данных и добавить результат в другую структуру. Весь этот набор операций должен выполняться атомарно. Никакой другой код не должен иметь возможности читать ни одну из структур данных до того, как данные этих структур будут полностью обновлены. Так как ясно, что простые ато марные операции не могут обеспечить необходимую защиту, то используется более сложный метод защиты — блокировки (lock).

Наиболее часто используемый тип блокировки в ядре Linux - это спин-блокировки (spin lock). Спин-блокировка — это блокировка, которую может удерживать не более чем один поток выполнения. Если поток выполнения пытается захватить блокиров ку, которая находится в состоянии конфликта (contended), т.е. уже захвачена, поток начинает выполнять постоянную циклическую проверку (busy loop) — "вращаться" (spin), ожидая на освобождение блокировки. Если блокировка не находится в со стоянии конфликта при захвате, то поток может сразу же захватить блокировку и продолжить выполнение. Циклическая проверка предотвращает ситуацию, в кото рой более одного потока одновременно может находиться в критическом участке.

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

Средства синхронизации в ядре Тот факт, что спин-блокировка, которая находится в состоянии конфликта, за ставляет потоки, ожидающие на освобождение этой блокировки, выполнять зам кнутый цикл (и, соответственно, тратить процессорное время), является важным.

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

Такое поведение вносит некоторые накладные затраты, основные из которых — это два переключения контекста. Вначале переключение на новый поток, а затем обрат ное переключение на заблокированный поток. Поэтому разумным будет использо вать спин-блокировку, когда время удержания этой блокировки меньше длительности двух переключений контекста. Так как у большинства людей есть более интересные занятия, чем измерение времени переключения контекста, то необходимо старать ся удерживать блокировки по возможности в течение максимально короткого пери ода времени1. В следующем разделе будут описаны семафоры (semaphore) — механизм блокировок, который позволяет переводить потоки, ожидающие на освобождение блокировки, в состояние ожидания, вместо того чтобы периодически проверять, не освободилась ли блокировка, находящаяся в состоянии конфликта.

Спин-блокировки япляются зависимыми от аппаратной платформы и реализова ны на языке ассемблера. Зависимый от аппаратной платформы код определен в за головочном файле. Интерфейс пользователя определен в файле . Рассмотрим пример использования спин-блокировок.

spinlock_t mr_lock = SPIN_LOCK_UNLOCKED

;

spin_lock (&mr_lock)

;

/* критический участок... */ spin_unlock(&mr_lock)

;

Б любой момент времени блокировка может удерживаться не более чем одним потоком выполнения. Следовательно, только одному потоку позволено войти в кри тический участок в данный момент времени. Это позволяет организовать защиту от состояний конкуренции на многопроцессорной машине. Заметим, что на одно процессорной машине блокировки не компилируются в исполняемый код, и, со ответственно, их просто не существует. Блокиропки играют роль маркеров, чтобы запрещать и разрешать вытеснение кода (преемптивпость) в режиме ядра. Если пре емптивность ядра отключена, то блокировки совсем не компилируются.

Сейчас это требование становится еще более важным, так как ядро является преемптивным.

Время, в течение которого удерживаются блокировки, эквивалентно времени задержки (латент пости) системного планировщика.

184 Глава Внимание: спин-блокировки не рекурсивны!

В отличие от реализаций в других операционных системах, спин-блокировки в операционной системе Linux не рекурсивны. Это означает, что если поток пытается захватить блокировку, которую он уже удерживает, то этот поток начнет периодическую проверку, ожидая, пока он сам не освободит блокировку. Но поскольку поток будет периодически проверять, не освободилась ли блокировка, он никогда не сможет ее освободить, и возникнет тупиковая ситуация (самобло кировка). Нужно быть внимательными!

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

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

Ядро предоставляет интерфейс, который удобным способом позволяет запретить прерывания и захватить блокировку. Использовать его можно следующим образом.

spinlock_t mr_lock = SPIN_LOCK_UNLOCKED

;

unsigned long flags

;

spin_lock_irqsave(&mr_lock, flags)

;

/* критический участок... */ spin_unlock_irqre_store(&rnr_lock, flags)

;

Подпрограмма spin_lock_irqsave () сохраняет текущее состояние системы прерываний, запрещает прерывания и захватывает указанную блокировку. Функция spin_unlock_irqrestore (), наоборот, освобождает указанную блокировку и вос станавливает предыдущее состояние системы прерываний. Таким образом, если пре рывания были запрещены, показанный код не разрешит их по ошибке. Заметим, что переменная flags передается по значению. Это потому, что указанные функции ча стично выполнены в виде макросов.

На однопроцессорной машине показанный пример только лишь запретит преры вания, чтобы предотвратить доступ обработчика прерывания к совместно исполь зуемым данным, а механизм блокировок скомпилирован не будет. Функции захвата и освобождения блокировки также соответственно запрещают и разрешают преем птивность ядра.

Средства синхронизации в ядре Что необходимо блокировать Важно, чтобы каждая блокировка была четко связана с тем, что она блокирует. Еще более важ но — это защищать данные, а не код. Несмотря на то что во всех примерах этой главы рас сматриваются критические участки, в основе этих критических участков лежат данные, которые требуют защиты, а никак не код. Если блокировки просто блокируют участки кода, то такой код труднопонимаем и подвержен состояниям гонок. Необходимо ассоциировать данные с соот ветствующими блокировками. Например, структура st r uct foo блокируется с помощью блокировки f oo_l ock. С данной блокировкой также необходимо ассоциировать некоторые данные. Если к некоторым данным осуществляется доступ, то необходимо гарантировать, что этот доступ будет безопасным. Наиболее часто это означает, что перед тем, как осуществить манипуляции с данными, необходимо захватить соответствующую блокировку и освободить эту блокировку нужно после завершения манипуляций.

Если точно известно, что прерывания разрешены, то нет необходимости восста навливать предыдущее состояние системы прерываний. Можно просто разрешить прерывания при освобождении блокировки. В этом случае оптимальным будет ис пользование функций spin_lock_irq() и spin_unlock_irq().

spinlock_t mr_lock = SPIN_LOCK_UNLOCKED

;

spin_lock_irq(&mr_lock)

;

/* критический участок... */ spin_unlock_irq(&mr_lock)

;

Для любого участка кода очень сложно гарантиропать, что прерывания всегда раз решены. В связи с этим не рекомендуется использовать функцию spinlock_irq ().

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

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

Другие средства работы со спин-блокировками Функция spin_lock_init () используется для инициализации спин-блокировок, которые были созданы динамически (переменная типа spinlock_t, к которой нет прямого доступа, а есть только указатель на нее).

Функция spin_try_lock () производит попытку захватить указанную спин-блоки ровку. Если блокировка находится в состоянии конфликта, то, вместо циклической проверки и ожидания на освобождение блокировки, эта функция возвращает нену левое значение. Если блокировка была захвачена успешно, то функция возвращает нуль. Аналогично функция spin_is_locked () возвращает ненулевое значение, если 186 Глава блокировка в данный момент захвачена. В противном случае возвращается нуль. Эта функция никогда не захватывает блокировку2.

В табл. 9.3 приведен полный список функций работы со спин-блокировками.

Таблица 9.3. Список функций работы со спин-блокировками Функция Описание spin_iock() Захватить указанную блокировку spin_lock_irq() Запретить прерывания на локальном процессоре и захватить указанную блокировку spin_lock_irqsave() Сохранить текущее состояние системы прерываний, запретить прерывания на локальном процессоре и захватить указанную блокировку spin_unlock() Освободить указанную блокировку spin_unlock_irq() Освободить указанную блокировку и разрешить прерывания на локальном процессоре spin_unlock_irqrestore() Освободить указанную блокировку и восстановить состояние си стемы прерываний на локальном процессоре в указанное перво начальное значение spi n_l ock_i ni t() Инициализировать объект типа spinlock_t в заданной области памяти spi n_tryl ock() Выполнить попытку захвата указанной блокировки и в случае не удачи возвратить ненулевое значение spin_is_locked() Возвратить ненулевое значение, если указанная блокировка в данный момент захвачена, и нулевое значение в противном случае Спин-блокировки и обработчики нижних половин Как было указано в главе 7, "Обработка нижних половин и отложенные действия", при использовании блокировок в работе с обработчиками нижних половин необхо димо принимать некоторые меры предосторожности. Функция spin_lock_bh() по зволяет захватить указанную блокировку и запретить все обработчики нижних по ловин. Функция spin_unlock_bh() выполняет обратные действия.

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

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

Вспомним, что два тасклета (tasklet) одного типа не могут выполняться парал лельно. Поэтому нет необходимости защищать данные, которые используются толь ко тасклетами одного типа.

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

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

В случае отложенных прерываний (softirq), независимо от того, это отложенные прерывания одного типа или разных, данные, совместно используемые обработ чиками отложенных прерываний, необходимо защищать с помощью блокировки.

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

Спин-блокировки чтения-записи Иногда в соответствии с целью использования блокировок их можпо разде лить два типа — блокировки чтения (reader lock) и блокировки записи (writer lock).

Рассмотрим некоторый список, который может обновляться и в котором может вы полняться поиск. Когда список обновляется (в него осуществляется запись), ника кой другой код не может параллельно осуществлять запись или чтение этого списка.

Запись означает исключительный доступ. С другой стороны, если в списке выполня ется поиск (чтение информации), важно только, чтобы никто другой не выполнял записи в список. Работа со списком заданий в системе (как обсуждалось в главе 3, "Управление процессами") аналогична только что описанной ситуации. Не удиви тельно, что список заданий в системе защищен с помощью спин-блокировки чтения записи (reader-writer spin lock).

Если работа со структурой данных может быть четко разделена на этапы чте ния/записи, как в только что рассмотренном случае, то имеет смысл использовать механизмы блокировок с аналогичной семантикой. Для таких ситуаций операцион ная система Linux предоставляет спин-блокировки чтения-записи. Спин-блокировки чтения-записи обеспечивают два варианта блокировки. Один или больше потоков выполнения, которые одновременно выполняют операции считывания, могут удер живать такую блокировку. Блокировка на запись, наоборот, может удерживаться в любой момент времени только одним потоком, осуществляющим запись, и никаких параллельных считываний не разрешается. Блокировки чтения-записи иногда также называются соответственно shared/exclusive (общая/ исключающая) или concurrent/ exclusive (параллельная/исключающая).

Инициализировать блокировку для чтения-записи можно с помощью следующего программного кода.

rwlock_t mr_rwlock = RW_LOCK_UNLOCKED

;

Следующий код осуществляет считывание.

read_lock(&mr_rwlock)

;

/* критический участок (только для считывания)... */ read unlock(&mr_rwlock)

;

188 Глава И наконец, показанный ниже код осуществляет запись.

write_lock(&mr_rwlock)

;

/* критический участок (чтение и запись)... */ write_unlock{&mr_rwlock)

;

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

Заметим, что блокировку, захваченную для чтения, нельзя "повышать" до блоки ровки, захваченной для записи. В следующем коде read_lock(&mr_rwlock)

;

write_lock(&mr_rwlock)

;

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

;

это касается и текущего потока. Если в каком-либо месте бу дет необходима запись, то нужно сразу же захватывать блокировку для записи. Если в вашем коде нет четкого разделения на код, который осуществляет считывание, и код, который осуществляет запись, то нет необходимости использовать блокировки чтения записи. В таком случае оптимальным будет использование обычных спин-блокировок.

Несколько потоков чтения безопасно могут удерживать одну и ту же блокировку чтения-записи. На самом деле один поток также может безопасно рекурсивно захва тывать одну и ту же блокировку для чтения. Это позволяет выполнить полезную и часто используемую оптимизацию. Если в обработчиках прерываний осуществляет ся только чтение и не выполняется запись, то можно "смешивать" использование блокировок с запрещением прерываний и без запрещения. Для защиты данных при чтении можно использовать функцию read_lock () вместо read_lock_irqsave ().

При обращении к данным для записи все равно необходимо запрещать прерывания, например использовать функцию wri te_l ock_i rqsave (), так как в обработчике прерывания может возникнуть взаимоблокировка в связи с ожиданием захвата бло кировки на чтение при захваченной блокировке на запись. В табл. 9.4 показан пол ный список средств работы с блокировками чтения-записи.

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

Спин-блокировки обеспечивают очень быстрые и простые блокировки.

Выполнение постоянных проверок в цикле является оптимальным, когда блокиров ки захватываются на очень короткое время и код не может переходить в состояние ожидания (например, в обработчиках прерываний). Если же период времени ожида ния на освобождение блокировки может быть большим или имеется потенциальная возможность перехода в состояние ожидания при захваченной блокировке, то зада ча может быть решена с помощью семафоров.

Средства синхронизации в ядре Таблица 9.4. Список функций работы со спин-блокировками чтения-записи Функция Описание read_lock () Захватить указанную блокировку на чтение Запретить прерывания на локальном процессоре и захватить ука read_lock_irq() занную блокировку на чтение read_lock_irqsave() Сохранить состояние системы прерываний на текущем процессо ре, запретить прерывания на локальном процессоре и захватить указанную блокировку на чтение read_unlock() Освободить указанную блокировку, захваченную для чтения read_unlock_irq () Освободить указанную блокировку, захваченную для чтения, и разрешить прерывания на локальном процессоре read_unlock_irqrestore () Освободить указанную блокировку, захваченную для чтения, и вос становить состояние системы прерываний в указанное значение write_lock() Захватить заданную блокировку на запись write_lock_irq() Запретить прерывания на локальном процессоре и захватить ука занную блокировку на запись write_lock_irqsave () Сохранить состояние системы прерываний на текущем процессо ре, запретить прерывания на локальном процессоре и захватить указанную блокировку на запись write_unlock () Освободить указанную блокировку, захваченную для записи write_unlock_irq () Освободить указанную блокировку, захваченную для записи, и разрешить прерывания на локальном процессоре write_unlock_irqrestore() Освободить указанную блокировку, захваченную для записи, и вос становить состояние системы прерываний в указанное значение write_trylock() Выполнить попытку захватить заданную блокировку на запись и в случае неудачи возвратить ненулевое значение rw_lock_init() Инициализировать объект типа rwlock_t в заданной области памяти rw is locked () Возвратить ненулевое значение, если указанная блокировка за хвачена, иначе возвратить нуль Семафоры В операционной системе Linux семафоры (semaphore) — это блокировки, кото рые переводят процессы в состояние ожидания. Когда задание пытается захватить семафор, который уже удерживается, семафор помещает это задание в очередь ожи дания (wait queue) и переводит это задание в состояние ожидания (sleep). Когда про цессы3, которые удерживают семафор, освобождают блокировку, одно из заданий очереди ожидания возвращается к выполнению и может захватить семафор.

Давайте снова возвратимся к аналогии двери и ключа. Когда человек, который хочет открыть дверь, подходит к двери, он может захватить ключ и войти в комна ту. Отличие состоит в том, что произойдет, если к двери подойдет другой человек.

В этом случае он записывает свое имя в список на двери и ложится поспать.

Как будет показано дальше, несколько процессов могут при необходимости одновременно удержи вать один семафор.

190 Глава Когда человек, который находился внутри комнаты, выходит из нее, он прове ряет список на двери. Если в списке есть чье-либо имя, то он выбирает первое из имен списка, дает соответствующему человеку пинка, будит его и позволяет войти в комнату. Таким образом, ключ (т.е. семафор) позволяет только одному человеку (т.е.

потоку) находиться в комнате (т.е. в критическом разделе) в один момент времени.

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

Из такого поведения семафоров, связанного с переводом процессов в состояние ожидания, можно сделать следующие интересные заключения.

• Так как задания, которые конфликтуют при захвате блокировки, переводятся в состояние ожидания и в этом состоянии ждут, пока блокировка не будет осво бождена, семафоры хорошо подходят для блокировок, которые могут удержи ваться в течение длительного времени.

• С другой стороны, семафоры не оптимальны для блокировок, которые удер живаются в течение очень короткого периода времени, так как накладные за траты на перевод процессов в состояние ожидания могут "перевесить" время, в течение которого удерживается блокировка.

• Так как поток выполнения во время конфликта при захвате блокировки нахо дится в состоянии ожидания, то семафоры можно захватывать только в кон тексте процесса. Контекст прерывания планировщиком не управляется.

• При удержании семафора (хотя разработчик может и не очень хотеть этого) процесс может переходить в состояние ожидания. Это не может привести к тупиковой ситуации, когда другой процесс попытается захватить блокировку (он просто переходит в состояние ожидания, что в конце концов дает возмож ность выполняться первому процессу).

• При захвате семафора нельзя удерживать спин-блокировку, поскольку процесс может переходить в состояние ожидания, ожидая на освобождение семафора, а при удержании спин-блокировки в состояние ожидания переходить нельзя.

Эти факты подчеркивают особенности использования семафоров по сравнению со спин-блокировками. В большинстве случаев выбор решения, использовать или не использовать семафоры, прост. Если код должен переходить в состояние ожида ния, что очень часто возникает при необходимости синхронизации с пространством пользователя, семафоры — единственное решение. Использовать семафоры всегда проще, даже если в них нет строгой необходимости, так как они предоставляют гиб кость, связанную с переходом процессов в состояние ожидания. Если же возникает необходимость выбора между семафорами и спид-блокировками, то решение должно основываться на времени удержания блокировки. В идеале, все блокировки необхо димо удерживать, по возможности, в течение наиболее короткого времени. При ис пользовании семафоров, однако, допустимы более длительные периоды удержания Средства синхронизации в ядре блокировок. В дополнение ко всему, семафоры не запрещают преемптивность ядра, и, следовательно, код, который удерживает семафор, может быть вытеснен. Это означает, что семафоры не оказывают вредного влияния на задержки (латентность) планировщика.

Последняя полезная функция семафоров — это то, что они позволяют иметь лю бое количество потоков, которые одновременно удерживают семафор. В то время как спин-блокировки позволяют удерживать блокировку только одному заданию в любой момент времени, количество заданий, которым разрешено одновременно удерживать семафор, может быть задано при декларации семафора. Это значение на зывается счетчиком использования (usage count) или просто счетчиком (count). Наиболее часто встречается ситуация, когда разрешенное количество потоков, которые од новременно могут удерживать семафор, равно одному, как и для спин-блокировок.

В таком случае счетчик использования равен единице и семафоры называются бинар ными семафорами (binary semaphore) (потому что он может удерживаться только одним заданием или совсем никем не удерживаться) или взаимоисключающими блокировками (mutex, мьютекс) (потому что он гарантирует взаимоисключающий доступ —mutual ex clusion). Кроме того, счетчику при инициализации может быть присвоено значение, большее единицы. В этом случае семафор называется счетным семафором (counting semaphore, семафор-счетчик), и он допускает количество потоков, которые одновре менно удерживают блокировку, не большее чем значение счетчика использования.

Семафоры-счетчики не используются для обеспечения взаимоисключающего досту па, так как они позволяют нескольким потокам выполнения одновременно находить ся в критическом участке. Вместо этого они используются для установки лимитов в определенном коде. В ядре они используются мало. Если вы используете семафор, то, скорее всего, вы используете взаимоисключающую блокировку (семафор со счет чиком, равным единице).

Семафоры были формализованы Эдсгером Вайбом Дейкстрой4 (Edsger Wybe Dijkstra) в 1968 году как обобщенный механизм блокировок. Семафор поддерживает две атомарные операции Р () и V (), название которых происходит от голландских слов Proben (тестировать) и Verhogen (выполнить инкремент). Позже эти операции на чали называть down () и up () соответственно.

В операционной системе Linux они имеют такое же название. Операция down () используется для того, чтобы захватить семафор путем уменьшения его счетчика на единицу. Если значение этого счетчика больше или равно нулю, то блокировка за хватывается успешно и задание может входить в критический участок. Если значе ние счетчика меньше нуля, то задание помещается в очередь ожидания и процес сор переходит к выполнению каких-либо других операций. Об использовании этой функции говорят в форме глагола— семафор опускается (down) для того, чтобы его захватить. Метод up () используется для того, чтобы освободить семафор после за вершения выполнения критического участка. Эту операцию называют поднятием (upping) семафора.

Доктор Дейкстра (1930-2002 г.) один из самых талантливых ученых за всю (конечно, не очень дол гую) историю существования вычислительной техники как области науки. Его многочисленные труды включают работы но проектированию операционных систем и по теории алгоритмов, сюда же входит концепция семафоров. Он родился в городе Роттердам, Нидерланды, и преподавал в университете штата Техас в течение 15 лет. Тем не менее, он был бы не очень доволен большим количеством директив GOTO в ядре Linux.

i 192 Глава Последний метод используется для инкремента значения счетчика. Если очередь ожидания семафора не пуста, то одно из заданий этой очереди возвращается к вы полнению и захватывает семафор.

Создание и инициализация семафоров Реализация семафоров зависит от аппаратной платформы и определена в файле. Структура st ruct semaphore представляет объекты типа се мафор. Статическое определение семафоров выполняется следующим образом.

static DECLARE_SEMAPHORE_GENERIC(name, count)

;

где name — имя переменной семефора, a count — счетчик семафора. Более короткая запись для создания взаимоисключающей блокировки (mutex), которая используют ся наиболее часто, имеет следующий вид.

static DECLARE_MUTEX(name)

;

где name — это снова имя переменной типа семафор. Чаще всего семафоры создают ся динамически, как часть больших структур данных. В таком случае для инициализа ции семафора, который создается динамически и на который есть только непрямая ссылка через указатель, необходимо использовать функцию sema_init(sem, count)

;

где sem— это указатель, a count — счетчик использования семафора. Аналогично для инициализации динамически создаваемой взаимоисключающей блокировки можно использовать функцию init_MUTEX(sem)

;

Неизвестно, почему слово "mutex" в имени функции init_MUTEX() выделено большими буквами и почему слово "init" идет перед ним, в то время как имя функ ции sema_init () таких особенностей не имеет. Тем не менее ясно, что это выгля дит не логично, и я приношу свои извинения за это несоответствие. Надеюсь, что после прочтения главы 7 ни у кого уже не будет вызывать удивление то, какие имена придумывают символам ядра.

Использование семафоров Функция down_interruptible () выполняет попытку захватить данный семафор.

Если эта попытка неудачна, то задание переводится в состояние ожидания с флагом TASK_INTERRUPTIBLE. Из материала главы 3 следует вспомнить, что такое состояние процесса означает, что задание может быть возвращено к выполнению с помощью сигнала и что такая возможность обычно очень ценная. Если сигнал приходит в тот момент, когда задание ожидает на освобождение семафора, то задание возвращает ся к выполнению, а функция down_interruptible () возвращает значение -EINTR.

Альтернативой рассмотренной функции выступает функция down (), которая пере водит задание в состояние ожидания с флагом TASK_UNINTERRUPTIBLE. В большин стве случаев это нежелательно, так как процесс, который ожидает на освобождение семафора, не будет отвечать на сигналы. Поэтому функция down_interruptible () используется значительно более широко, чем функция down (). Да, имена этих функ ций, конечно, далеки от идеала.

Средства синхронизации в ядре Функция down_trylock () используется для неблокирующего захвата указанного семафора. Если семафор уже захвачен, то функция немедленно возвращает ненуле вое значение. В случае успеха по захвату блокировки возвращается нулевое значение и захватывается блокировка.

Для освобождения захваченного семафора необходимо вызвать функцию up ().

Рассмотрим следующий пример.

/* объявление и описание семафора с именем mr_sem и первоначальным значением счетчика, равным 1 */ static DECLARE_MUTEX(mr_sem)

;

if (down_interruptible(&mr_sem)) /* получен сигнал и семафор не захвачен */ /* критический участок... */ /* освободить семафор */ up(&mr_sem)

;

Полный список функций работы с семафорами приведен в табл. 9.5.

Таблица 9.5. Список функций работы с семафорами Функция Описание Инициализация динамически созданного сема sema_init(struct semaphore *, int) фора и установка для него указанного значения счетчика использования init_MUTEX(struct semaphore *) Инициализация динамически созданного сема фора и установка его счетчика использования в значение init_MUTEX_LOCKED (struct semaphore *) Инициализация динамически созданного семафо ра и установка его счетчика использования в зна чение 0 (т.е. семафор изначально заблокирован) down_interruptible(struct semaphore *) Выполнить попытку захватить семафор и пере йти в прерываемое состояние ожидания, если семафор находится в состоянии конфликта при захвате (contended) down(struct semaphore *) Выполнить попытку захватить семафор и пере йти в непрерываемое состояние ожидания, если семафор находится в состоянии конфликта при захвате (contended) down_trylock(struct semaphore *) Выполнить попытку захватить семафор и не медленно возвратить ненулевое значение, если семафор находится в состоянии конфликта при захвате (contended) up(struct semaphore *) Освободить указанный семафор и возвратить к выполнению ожидающее задание, если такое есть Глава Семафоры чтения-записи Семафоры, так же как и спин-блокировки, могут быть типа чтения-записи.

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

Семафоры чтения-записи представляются с помощью структуры st ruct rw_ semaphore, которая определена в файле. Статически определенный семафор чтения-записи может быть создан с помощью функции static DECLARE_RWSEM(name)

;

где name — это имя нового семафора.

Семафоры чтения-записи, которые создаются динамически, могут быть инициа лизированы с помощью следующей функции.

init_rwsem(struct rw_semaphore *sem) Все семафоры чтения-записи являются взаимоисключающими (mutex), т.е. их счетчик использования равен единице. Любое количество потоков чтения может одновременно удерживать блокировку чтения, если при этом нет ни одного потока записи. И наоборот, только один поток записи может удерживать блокировку, захва ченную на запись, если нет ни одного потока чтения. Все семафоры чтения-записи используют непрерываемое состояние ожидания, поэтому существует только одна версия функции down (). Рассмотрим следующий пример.

static DECLARE_RWSEM(mr_rwsem)

;

/* попытка захватить семафор для чтения */ down_read(&mr_rwsem)

;

/* критический участок (только чтение).. */ /* освобождаем семафор */ up_read(&rar_rwsem)

;

/*... */ /* попытка захватить семафор на запись */ down_write(&mr_rwsem)

;

/* освобождаем семафор */ /* критический участок (чтение и запись)... */ up write(&mr rwsem)

;

.

Для семафоров есть реализации функций down_read_trylock () и down_write_ trylock (). Каждая из них принимает один параметр — указатель на семафор чте ния-записи. Обе функции возвращают ненулевое значение, если блокировка захва чена успешно, и нуль, если блокировка находится в состоянии конфликта. Следует быть внимательными — поведение этих функций противоположно поведению анало гичных функций для обычных семафоров, причем без всякой на то причины!

Семафоры чтения-записи имеют уникальную функцию, аналога которой нет для спин-блокировок чтения-записи. Это функция downgradewriter (), которая авто Средства синхронизации в ядре матичсски превращает блокировку, захваченную на запись, в блокировку, захвачен ную на чтение.

Семафоры чтения-записи, так же как и спин-блокировки аналогичного типа, должны использоваться, только если есть четкое разделение между участками кода, которые осуществляют чтение, и участками кода, которые осуществляют запись.

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

Сравнение спин-блокировок и семафоров Понимание того, когда использовать спин-блокировки, а когда семафоры являет ся важным для написания оптимального кода. Однако во многих случаях выбирать очень просто. В контексте прерывания могут использоваться только спин-блокиров ки, и только семафор может удерживаться процессом, который находится в состо янии ожидания. В табл. 9.6 показан обзор требований того, какой тип блокировок использовать.

Таблица 9.6. Что следует использовать: семафоры или спин-блокировки Требование Рекомендуемый тип блокировки Требование Рекомендуемый тип блокировки Блокировка с малыми накладными затрата- Спин-блокировки более предпочтительны Блокировка с малыми накладными затрата- Спин-блокировки более предпочтительны ми (low overhead) ми (low overhead) Малое время удержания блокировки Спин-блокировки более предпочтительны Малое время удержания блокировки Спин-блокировки более предпочтительны Длительное время удержания блокировки Семафоры более предпочтительны Длительное время удержания блокировки Семафоры более предпочтительны Необходимо использовать блокировку в Необходима спин-блокировка Необходимо использовать блокировку в Необходима спин-блокировка контексте прерывания контексте прерывания Необходимо переходить в состояние ожи- Необходимо использовать семафоры Необходимо переходить в состояние ожи- Необходимо использовать семафоры дания (steep) при захваченной блокировке дания (steep) при захваченной блокировке Условные переменные Условные переменные (conditional variable, completion variable) — простое сред ство синхронизации между двумя заданиями, которые работают в режиме ядра, ког да необходимо, чтобы одно задание послало сигнал другому о том, что произошло некоторое событие. При этом одно задание ожидает на условной переменной, пока другое задание не выполнит некоторую работу. Когда другое задание завершит вы полнение своей работы, оно использует условную переменную для того, чтобы воз вратить к выполнению все ожидающие на ней задания. Если это кажется похожим на работу семафора, то именно так оно и есть, идея та же. В действительности, услов ные переменные просто обеспечивают простое решение проблемы, для которой в других ситуациях используются семафоры. Например, в системном вызове vfork() условная переменная используется для возврата к выполнению родительского про цесса при завершении порожденного.

Условные переменные представляются с помощью структуры struct completion, которая определена в файле .

196 Глава Статически условная переменная может быть создана с помощью макроса DECLARE_COMPLETI0N(mr_comp)

;

Динамически созданная условная переменная может быть инициализирована с помощью функции init_completion ().

Задание, которое должно ожидать на условной переменной, вызывает функцию wait_for_completion (). После того как наступило ожидаемое событие, вызов функции complete () посылает сигнал заданию, которое ожидает на условной пере менной, и это задание возвращается к выполнению. В табл. 9.7 приведены методы работы с условными переменными.

Таблица. 9.7. Методы работы с условными переменными Метод Описание init_completion(struct completion *) Инициализация динамически созданной услов ной переменной в заданной области памяти wait_for_completion(struct completion *) Ожидание сигнала на указанной условной переменной complete(struct completion *) Отправка сигнала всем ожидающим заданиям и возвращение их к выполнению Для примеров использования условных переменных смотрите файлы kernel/ sched.с и kernel/fork.с. Наиболее часто используются условные переменные, которые создаются динамически, как часть структур данных. Код ядра, который ожидает па инициализацию структуры данных, вызывает функцию wait_for_ completion(). Когда инициализация закончена, ожидающие задания возвращаются к выполнению с помощью вызова функции complete().

BLK: Большая блокировка ядра Добро пожаловать к "рыжему пасынку" ядра. Большая блокировка ядра (Big Kernel Lock, BKL) — это глобальная спин-блокировка, которая была создана специ ально для того, чтобы облегчить переход от первоначальной реализации SMP n опе рационной системе Linux к мелкоструктурным блокировкам. Блокировка BKL имеет следующие интересные свойства.

• Во время удержания BKL можно переходить в состояние ожидания. Блокировка автоматически освобождается, когда задание переходит в состояние ожидания, и снова захватывается, когда задание планируется на выполнение. Конечно, это не означает, что безопасно переходить в состояние ожидания при удержа нии BKL, просто это можно делать и это не приведет к взаимоблокировке.

• Блокировка BKL рекурсивна. Один процесс может захватывать эту блокировку несколько раз подряд, и это не приведет к самоблокировке, как в случае обыч ных спин-блокировок.

• Блокировка BKL может использоваться только в контексте процесса.

• Блокировка BKL — это от лукавого.

Средства синхронизации в ядре Рассмотренные свойства дали возможность упростить переход от ядер серии 2.0 к серии 2.2. Когда в ядро 2-0 была введена поддержка SMP, только одно задание могло выполняться в режиме ядра в любой момент времени (конечно, сейчас ядро распа раллелено очень хорошо— пройден огромный путь). Целью создания ядра серии 2. было обеспечение возможности параллельного выполнения кода ядра на нескольких процессорах. Блокировка BKL была введена для того, чтобы упростить переход к мелкоструктурным блокировкам. В те времена она оказала большую помощь, а сегод ня она приводит к ухудшению масштабируемости5.

Использовать блокировку BKL не рекомендуется. На самом деле, новый код ни когда не должен использовать BKL. Однако эта блокировка все еще достаточно ин тенсивно используется в некоторых частях ядра. Поэтому важно понимать особен ности большой блокировки ядра и интерфейса к ней. Блокировка BKL ведет себя, как обычная спин-блокировка, за исключением тех особенностей, которые были рас смотрены выше. Функция lock_kernel () позволяет захватить блокировку, а функ ция unlock_kernel () — освободить блокировку. Каждый поток выполнения может рекурсивно захватывать эту блокировку, но после этого необходимо столько же раз вызвать функцию unlock_kernel (). При последнем вызове функции освобождения блокировки блокировка будет освобождена. Функция kernellocked () возвращает ненулевое значение, если блокировка в данный момент захвачена, в противном слу чае возвращается нуль. Эти интерфейсы определены в файле .

Рассмотрим простой пример использования этой блокировки.

lock_kernel()

;

/* * Критический раздел, который синхронизирован со всеми пользователями * блокировки BKL...

* Заметим, что здесь можно безопасно переходить в состояние ожидания * и блокировка будет прозрачным образом освобождаться.

* После перепланирования блокировка будет прозрачным образом снова * захватываться.

* Это гарантирует, что не возникнет состояния взаимоблокировки, * но все-таки лучше не переходить в состояние ожидания, * если необходимо гарантировать защиту данных!

*/ unlock_kernel()

;

Когда эта блокировка захвачена, происходит запрещение преемптивности. Для ядер, скомпилированных под однопроцессорную машину, код BKL на самом деле не выполняет никаких блокировок. В табл. 9.8 приведен полный список функций рабо ты с BKL.

Хотя, может быть, она и не такая страшная, какой ее иногда пытаются представить, вес же неко торые люди считают ее "воплощением дьявола" в ядре.

198 Глава Таблица 9.8. Функции работы с большой блокировкой ядра Функция Описание lock_kernel() Захватить блокировку BKL unlock_kernel() Освободить блокировку BKL kernel_locked() Возвратить ненулевое значение, если блокировка захвачена, и нуль- в противном случае Одна из самых главных проблем, связанных с большой блокировкой ядра, — как определить, что защищается с помощью данной блокировки. Часто блокировка BKL ассоциируется с кодом (например, она "синхронизирует вызовы функции foo () "), а не с данными ("защита структуры foo "). Это приводит к тому, что заменить BKL обычными сиин-блокировками бывает сложно, потому что нелегко определить, что же все-таки необходимо блокировать. На самом деле, подобная замена еще более сложна, так как необходимо учитывать все взаимоотношения между всеми участками кода, которые используют эту блокировку.

Секвентные блокировки Секвентная блокировка (seq lock) — это новый тип блокировки, который появил ся в ядрах серии 2.6. Эти блокировки предоставляют очень простой механизм чте ния и записи совместно используемых данных. Работа таких блокировок основана на счетчике последовательности событий. Перед записью рассматриваемых данных захватывается спин-блокировка, и значение счетчика увеличивается на единицу.

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 10 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.