Принципы работы в UNIX-подобных ОС на примере Linux. Создание своего легковесного процесса

О дин из самых раздражающих моментов при переходе от среды на базе Windows к использованию командной строки – потеря легкой многозадачности. Даже в Linux, если вы используете X Window system, вы можете использовать мышь, чтобы просто нажать на новую программу и открыть ее. В командной строке, однако, вы в значительной степени застряли с монозадачеостью. В этой статье мы покажем вам как перейти к многозадачности в Linux с помощью командной строки.

Фоновое и приоритетное управление процессами

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

Незащищенный

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

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

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

Из-за этих недостатков возникают огромные проблемы с управлением процессом фона и переднего плана. Лучшее решение – использовать утилиту командной строки «screen», как показано ниже.

Но сначала – вы откроете новый сеанс SSH

Не забывайте, что вы просто открываете новый сеанс SSH.

Это может быть неудобно, чтобы открыть новые сессии все время. И именно тогда вам нужен “screen”

Утилита screen позволяет создавать несколько рабочих процессов, открытых в то же время – ближайший аналог “windows”. По умолчанию он доступен в обычных репозиториях Linux. Установите его в CentOS/RHEL с помощью следующей команды:

Sudo yum install screen

Открытие нового экрана

Теперь начните сеанс, набрав “screen”.

Это создаст пустое окно в рамках существующего сеанса SSH и даст ему номер, который показан в заголовке, как это:

Наш экран здесь имеет номер “0”, как показано. На этом скриншоте мы используем фиктивную команду” read”, чтобы заблокировать терминал и заставить его ждать ввода. Теперь скажем, мы хотим сделать что-то еще, пока мы ждем.

Чтобы открыть новый экран и сделать что-то другое, мы печатаем:

Ctrl+a c

“ctrl+a” является комбинацией клавиш по умолчанию для управления экранами в программе экрана. То, что вы вводите после него, определяет действие. Так например:

ctrl+a c – C активирует новый экран
ctrl+a [число] – переход к определенному номеру экрана
ctrl+a k – K отключает текущий экран
ctrl+a n – Переход к экрану n
ctrl+a “- отображает все активные экраны в сеансе

Если мы нажмем “ctrl+a c”, мы получим новый экран с новым номером.

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

Процессы в UNIX

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

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

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

Типы процессов

В операционных системах UNIX выделяется три типа процессов: системные , процессы-демоны и прикладные процессы .

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

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

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

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

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

Атрибуты процесса

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

· Идентификатор процесса (PID) , позволяющий ядру системы различать процессы. Когда создается новый процесс, ядро присваивает ему следующий свободный (т.е. не ассоциированный ни с каким процессом) идентификатор. Присвоение идентификатора обычно происходит по возрастающий, т.е. идентификатор нового процесса больше, чем идентификатор процесса, созданного перед ним. Если идентификатор достигает максимального значения (обычно – 65737), следующий процесс получит минимальный свободный PID и цикл повторяется. Когда процесс завершает работу, ядро освобождает использовавшийся им идентификатор.

· Идентификатор родительского процесса (PPID) – идентификатор процесса, породившего данный процесс. Все процессы в системе, кроме системных процессов и процесса init , являющегося прародителем остальных процессов, порождены одним из существующих или существовавших ранее процессов.

· Поправка приоритета (NI) – относительный приоритет процесса, учитываемый планировщиком при определении очередности запуска. Фактическое же распределение процессорных ресурсов определяется приоритетом выполнения (атрибут PRI ), зависящим от нескольких факторов, в частности от заданного относительного приоритета. Относительный приоритет не изменяется системой на всем протяжении жизни процесса, хотя может быть изменен пользователем или администратором при запуске процесса с помощью команды nice . Диапазон значений инкремента приоритета в большинстве систем – от -20 до 20. Если инкремент не задан, используется стандартное значение 10. Положительный инкремент означает снижение текущего приоритета. Обычные пользователи могут задавать только положительный инкремент и, тем самым, только снижать приоритет. Пользователь root может задать отрицательный инкремент, который повышает приоритета процесса и, тем самым, способствует его более быстрой работе. В отличии от относительного приоритета приоритет выполнения процесса динамически изменяется планировщиком.

· Терминальная линия (TTY) – терминал или псевдотерминал, связанный с процессом. С этим терминалом по умолчанию связаны стандартные потоки : входной , выходной и поток сообщений об ошибках. Потоки (программные каналы ) являются стандартным средством межпроцессного взаимодействия в ОС UNIX. Процессы-демоны не связаны с терминалом.

· Реальный (UID) и эффективный (EUID) идентификаторы пользователя . Реальным идентификатором пользователя данного процесса является идентификатор пользователя, запустившего процесс. Эффективный идентификатор служит для определения прав доступа процесса к системным ресурсам (в первую очередь к ресурсам файловой системы). Обычно реальный и эффективный идентификаторы совпадают, т.е. процесс имеет в системе те же права, что и пользователь, запустивший его. Однако существует возможность задать процессу более широкие права, чем права пользователя, путем установки бита SUID , когда эффективному идентификатору присваивается значение идентификатора владельца выполняемого файла (например, пользователя root ).

· Реальный (GID) и эффективный (EGID) идентификаторы группы. Реальный идентификатор группы равен идентификатору основной или текущей группы пользователя, запустившего процесс. Эффективный идентификатор служит для определения прав доступа к системным ресурсам от имени группы. Обычно эффективный идентификатор группы совпадает с реальным. Но если для выполняемого файла установлен бит SGID , такой файл выполняется с эффективным идентификатором группы-владельца.

ЛАБОРАТОРНАЯ РАБОТА №3

МНОГОЗАДАЧНОЕ ПРОГРАММИРОВАНИЕ В LINUX

1. Цель работы: Ознакомиться с компилятором gcc, методикой отладки программ, функциями работы с процессами.

2. Краткие теоретические сведения.

Минимальным набором ключей компилятора gcc являются - Wall (выводить все ошибки и предупреждения) и - o (output file):

gcc - Wall - o print_pid print_pid. c

Команда создаст исполняемый файл print_pid.

Стандартная библиотека C (libc, реализованная в Linux в glibc), использует возможности многозадачности Unix System V (далее SysV). В libc тип pid_t определен как целое, способное вместить в себе pid. Функция, которая сообщает pid текущего процесса, имеет прототип pid_t getpid (void) и определена вместе с pid_t в unistd. h и sys/types. h).

Для создания нового процесса используется функция fork:

pid_t fork(void)

Вставляя задержку случайной длины при помощи функций sleep и rand, можно нагляднее увидеть эффект многозадачности:

это заставит программу "заснуть" на случайное число секунд: от 0 до 3.

Чтобы в качестве дочернего процесса вызвать функцию, достаточно вызвать ее после ветвления:

// если выполняется дочерний процесс, то вызовем функцию

pid=process(arg);

// выход из процесса

Часто в качестве дочернего процесса необходимо запускать другую программу. Для этого применяется функции семейства exec:

// если выполняется дочерний процесс, то вызов программы

if (execl("./file","file",arg, NULL)<0) {

printf("ERROR while start process\n");

else printf("process started (pid=%d)\n", pid);

// выход из процесса

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

#include

pid_t wait(int *status) - приостанавливает выполнение текущего процесса до завершения какого-либо из его процессов-потомков.

pid_t waitpid (pid_t pid, int *status, int options) - приостанавливает выполнение текущего процесса до завершения заданного процесса или проверяет завершение заданного процесса.

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

status=waitpid(pid,&status, WNOHANG);

if (pid == status) {

printf("PID: %d, Result = %d\n", pid, WEXITSTATUS(status)); }

Для изменения приоритетов порожденных процессов используются функции setpriority и. Приоритеты задаются в диапазоне от -20 (высший) до 20 (низший), нормальное значение - 0. Заметим, что повысить приоритет выше нормального может только суперпользователь!

#include

int process(int i) {

setpriority(PRIO_PROCESS, getpid(),i);

printf("Process %d ThreadID: %d working with priority %d\n",i, getpid(),getpriority(PRIO_PROCESS, getpid()));

return(getpriority(PRIO_PROCESS, getpid()));

Для уничтожения процесса служит функция kill:

#include

int kill(pid_t pid, int sig);

Если pid > 0, то он задает PID процесса, которому посылается сигнал. Если pid = 0, то сигнал посылается всем процессам той группы, к которой принадлежит текущий процесс.

sig - тип сигнала. Некоторые типы сигналов в Linux:

SIGKILL Этот сигнал приводит к немедленному завершению процесса. Этот сигнал процесс не может игнорировать.

SIGTERM Этот сигнал является запросом на завершение процесса.

SIGCHLD Система посылает этот сигнал процессу при завершении одного из его дочерних процессов. Пример:

if (pid[i] == status) {

printf("ThreadID: %d finished with status %d\n", pid[i], WEXITSTATUS(status));

else kill(pid[i],SIGKILL);

3. Методические указания.

3.1. Для ознакомления с опциями компилятора gcc, описанием функций языка С используйте инструкции man и info.

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

3.3. В файловом менеджере Midnight Commander имеется буфер команд, вызываемый сочетанием клавиш - H, перемещение по которому производится стрелками управления курсором (вверх и вниз). Для вставки команды из буфера в командную строку используется клавиша , для редактирования команды из буфера - клавиши <- и ->, и .

3.4. Помните, что текущая директория не содержится в path, поэтому из командной строки необходимо запускать программу как "./print_pid". В MC достаточно навести курсор на файл и нажать .

3.5. Для просмотра результата выполнения программы используйте сочетание клавиш - O. Они работают и в режиме редактирования файла.

3.6. Для протоколирования результатов выполнения программ целесообразно использовать перенаправление вывода с консоли в файл: ./test > result. txt

3.7. Для доступа к файлам, созданным на сервере Linux, применяйте протокол ftp, клиентская программа которого имеется в Windows 2000 и встроена в файловый менеджер FAR. При этом учетная запись и пароль те же, что и при подключении по протоколу ssh.

4.1. Ознакомиться с опциями компилятора gcc, методикой отладки программ.

4.2. Для вариантов заданий из лабораторной работы №1 написать и отладить программу, реализующую порожденный процесс.

4.3. Для вариантов заданий из лабораторной работы №1 написать и отладить программу, реализующую родительский процесс, вызывающий и отслеживающий состояние порожденных процессов - программ (ждущий их завершения или уничтожающий их, в зависимости от варианта).

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

5. Варианты заданий. См. варианты заданий из лабораторной работы №1

6. Содержание отчета.

6.1. Цель работы.

6.2. Вариант задания.

6.3. Листинги программ.

6.4. Протоколы выполнения программ.

7. Контрольные вопросы.

7.1. Особенности компиляции и запуска С-программ в Linux.

7.2. Что такое pid, как его определить в операционной системе и программе?

7.3. Функция fork - назначение, применение, возвращаемое значение.

7.4. Как запустить на выполнение в порожденном процессе функцию? Программу?

7.5. Способы синхронизации родительского и дочерних процессов.

7.6. Как узнать состояние порожденного процесса при его завершении и возвращенное им значение?

7.7. Как управлять приоритетами процессов?

7.8. Как уничтожить процесс в операционной системе и программе?

Продолжаем тему многопоточности в ядре Linux. В прошлый раз я рассказывала про прерывания, их обработку и tasklet’ы, и так как изначально предполагалось, что это будет одна статья, в своем рассказе о workqueue я буду ссылаться на tasklet’ы, считая, что читатель уже с ними знаком.
Как и в прошлый раз, я постараюсь сделать мой рассказ максимально подробным и детальным.

Статьи цикла:

Многозадачность в ядре Linux: workqueue

Workqueue

Workqueue - это более сложные и тяжеловесные сущности, чем tasklet’ы. Я даже не буду пытаться описать здесь все тонкости реализации, но самое важное, надеюсь, я разберу более или менее подробно.
Workqueue, как и tasklet’ы, служат для отложенной обработки прерываний (хотя их можно использовать и для других целей), но, в отличие от tasklet’ов, выполняются в контексте kernel-процесса, соответственно, они не обязаны быть атомарными и могут использовать функцию sleep(), различные средства синхронизации и т.п.

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

В этом темном деле замешаны несколько сущностей.
Во-первых, work item (для краткости просто work) - это структура, описывающая функцию (например, обработчик прерывания), которую мы хотим запланировать Его можно воспринимать как аналог структуры tasklet. Tasklet’ы при планировании добавлялись в очереди, скрытые от пользователя, теперь же нам нужно использовать специальную очередь - workqueue .
Tasklet’ы разгребаются функцией-планировщиком, а workqueue обрабатывается специальными потоками, которые зовутся worker’ами.
Worker ’ы обеспечивают асинхронное исполнение work’ов из workqueue. Хотя они вызывают work’и в порядке очереди, в общем случае о строгом, последовательном выполнении речи не идет: все-таки здесь имеют место вытеснение, сон, ожидание и т.д.

Вообще, worker’ы - это kernel-потоки, то есть ими управляет основной планировщик ядра Linux. Но worker’ы частично вмешиваются в планирование для дополнительной организации параллельного исполнения work’ов. Про это подробнее пойдет ниже.

Чтобы очертить основные возможности механизма workqueue, я предлагаю изучить API.

Про очередь и ее создание

alloc_workqueue(fmt, flags, max_active, args...)
Параметры fmt и args - это printf-формат для имени и аргументы к нему. Параметр max_activate отвечает за максимальное число work’ов, которые из этой очереди могут исполняться параллельно на одном CPU.
Очередь можно создать со следующими флагами:

WQ_HIGHPRI
WQ_UNBOUND
WQ_CPU_INTENSIVE
WQ_FREEZABLE
WQ_MEM_RECLAIM

Особое внимание следует уделить флагу WQ_UNBOUND . По наличию этого флага очереди делятся на привязанные и непривязанные.
В привязанных очередях work’и при добавлении привязываются к текущему CPU, то есть в таких очередях work’и исполняются на том ядре, которое его планирует. В этом плане привязанные очереди напоминают tasklet’ы.
В непривязанных очередях work’и могут исполняться на любом ядре.

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

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

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

Флаги WQ_FREEZABLE и WQ_MEM_RECLAIM специфичны и выходят за рамки темы, поэтому подробно на них останавливаться не будем.

Иногда есть смысл не создавать свои собственные очереди, а использовать общие. Основные из них:

system_wq - привязанная очередь для быстрых work’ов
system_long_wq - привязанная очередь для work’ов, которые предположительно будут исполняться долго
system_unbound_wq - непривязанная очередь

Про work’и и их планирование

Теперь разберемся с work’ами. Сначала взглянем на макросы инициализации, декларации и подготовки:
DECLARE(_DELAYED)_WORK(name, void (*function)(struct work_struct *work)); /* на этапе компиляции */ INIT(_DELAYED)_WORK(_work, _func); /* во время исполнения */ PREPARE(_DELAYED)_WORK(_work, _func); /* для изменения исполняемой функции */
В очереди work’и добавляются с помощью функций:
bool queue_work(struct workqueue_struct *wq, struct work_struct *work); bool queue_delayed_work(struct workqueue_struct *wq, struct delayed_work *dwork, unsigned long delay); /* work будет добавлен в очередь только по истечению delay */
Вот на этом стоит остановиться поподробнее. Хотя мы в качестве параметра указываем очередь, на самом деле, work’и кладутся не в сами workqueue, как это может показаться, а в совершенно другую сущность - в список-очередь структуры worker_pool. Структура worker_pool , по сути, самая главная сущность в организации механизма workqueue, хотя для пользователя она остается за кулисами. Именно с ними работают worker’ы, и именно в них содержится вся основная информация.

Теперь посмотрим, какие пулы есть в системе.
Для начала пулы для привязанных очередей (на картинке). Для каждого CPU статически выделяются два worker pool: один для высокоприоритетных work’ов, другой - для work’ов с нормальным приоритетом. То есть, если ядра у нас четыре, то привязанных пулов будет всего восемь, не смотря на то, что workqueue может быть сколько угодно.
Когда мы создаем workqueue, у него для каждого CPU выделяется служебный pool_workqueue (pwq). Каждый такой pool_workqueue ассоциирован с worker pool, который выделен на том же CPU и соответствует по приоритету типу очереди. Через них workqueue взаимодействует с worker pool.
Worker’ы исполняют work’и из worker pool без разбора, не различая, к какому workqueue они принадлежали изначально.

Для непривязанных очередей worker pool’ы выделяются динамически. Все очереди можно разбить на классы эквивалентности по их параметрам, и для каждого такого класса создается свой worker pool. Доступ к ним осуществляется с помощью специальной хэш-таблицы, где ключом служит набор параметров, а значением, соответственно, worker pool.
На самом деле у непривязанных очередей все немножко сложнее: если у привязанных очередей создавались pwq и очереди для каждого CPU, то здесь они создаются для каждого узла NUMA , но это уже дополнительная оптимизация, которую в деталях рассматривать не будем.

Всякие мелочи

Еще приведу несколько функций из API для полноты картины, но подробно о них говорить не буду:
/* Принудительное завершение */ bool flush_work(struct work_struct *work); bool flush_delayed_work(struct delayed_work *dwork); /* Отменить выполнение work */ bool cancel_work_sync(struct work_struct *work); bool cancel_delayed_work(struct delayed_work *dwork); bool cancel_delayed_work_sync(struct delayed_work *dwork); /* Удалить очередь */ void destroy_workqueue(struct workqueue_struct *wq);

Как worker’ы справляются со своей работой

Теперь, как мы познакомились с API, давайте попробуем подробнее разобраться, как это все работает и управляется.
У каждого пула есть набор worker’ов, которые разгребают задачи. Причем, количество worker’ов меняется динамически, подстраиваясь под текущую ситуацию.
Как мы уже выяснили, worker’ы - это потоки, которые в контексте ядра выполняют work’и. Worker достает их по порядку один за другим из ассоциированного с ним worker pool, причем work’и, как мы уже знаем, могут принадлежать к разным исходным очередям.

Worker’ы условно могут находиться в трех логических состояниях: они могут быть простаивающими, запущенными или управляющими.
Worker может простаивать и ничего не делать. Это, например, когда все work’и уже исполняются. Когда worker переходит в это состояние, он засыпает и, соответственно, не будет исполняться до тех пор, пока его не разбудят;
Если не требуется управление пулом и список запланированных work’ов не пуст, то worker начинает исполнять их. Такие worker’ы условно будем называть запущенными .
Если же необходимо, worker берет на себя роль управляющего пулом. У пула может быть либо только один управляющий worker, либо не быть его вообще. Его задача - поддерживать оптимальное число worker’ов на пул. Как он это делает? Во-первых, удаляются worker’ы, которые достаточно долго простаивают. Во-вторых, создаются новые worker’ы, если выполняются сразу три условия:

еще есть задачи на выполнение (work’и в пуле)
нет простаивающих worker’ов
нет работающих worker’ов (то есть активных и при этом не спящих)

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

Учет работающих worker’ов осуществляется прямо из основного планировщика ядра Linux. Такой механизм управления обеспечивает оптимальный уровень параллельности (concurrency level), не давая workqueue создавать слишком много worker’ов, но и не заставляя work’и без нужды ждать слишком долго.

Те, кому интересно, могут посмотреть функцию worker’а в ядре, называется она worker_thread().

Со всеми описанными функциями и структурами можно подробнее ознакомиться в файлах include/linux/workqueue.h , kernel/workqueue.c и kernel/workqueue_internal.h . Также по workqueue есть документация в Documentation/workqueue.txt .

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

Таким образом, мы рассмотрели механизмы отложенной обработки прерываний в ядре Linux - tasklet и workqueue, которые представляют собой особую форму многозадачности. Про прерывания, tasklet’ы и workqueue можно почитать в книге "Linux Device Drivers " авторов Jonathan Corbet, Greg Kroah-Hartman, Alessandro Rubini, правда, информация там временами устаревшая.

Статьи цикла:

Многозадачность в ядре Linux: workqueue

Workqueue

Чтобы очертить основные возможности механизма workqueue, я предлагаю изучить API.

Про очередь и ее создание

WQ_HIGHPRI
WQ_UNBOUND
WQ_CPU_INTENSIVE
WQ_FREEZABLE
WQ_MEM_RECLAIM

Иногда есть смысл не создавать свои собственные очереди, а использовать общие. Основные из них:

system_wq - привязанная очередь для быстрых work’ов
system_long_wq - привязанная очередь для work’ов, которые предположительно будут исполняться долго
system_unbound_wq - непривязанная очередь

Про work’и и их планирование

Всякие мелочи

Как worker’ы справляются со своей работой

еще есть задачи на выполнение (work’и в пуле)
нет простаивающих worker’ов
нет работающих worker’ов (то есть активных и при этом не спящих)

Те, кому интересно, могут посмотреть функцию worker’а в ядре, называется она worker_thread().