Разработка ядра Linux

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

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

intqueue_delayed_work(struct workqueue_struct *wq,

struct work_struct *work, unsigned long delay);

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

flush_workqueue(struct workqueue_struct *wq);

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

Старый механизм очередей заданий

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

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

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

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

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

Какие обработчики нижних половин необходимо использовать

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