5.1. Структуры данных ОС, связанные с потоком
5.2. Планирование потока. Создание потока. Управление потоками
5.3. Уничтожение потока
5.4. Управление потоками (примеры реализаций)
Основные сокращения темы:
ОС –
ULT –
KLT –
5.1. Структуры данных ОС, связанные с потоком
Аналогично структуре данных процессов (Раздел 4.2)
Структуры данных ОС, связанные с планированием.
При планировании потоков ядро ОС поддерживает набор структур данных, называемых в совокупности базой данных диспетчера ядра, позволяет отслеживать потоки, ждущие выполнения принадлежности процесса.
При создании потоков, так же как и при создании процессов, ОС генерирует специальную информационную структуру – описатель потока, который содержит идентификатор потока, данные о правах доступа и приоритете, о состоянии потока и другую информацию. Описатель потока можно разделить на две части: атрибуты блока управления и контекст потока. Заметим, что в случае многопоточной системы процессы контекста не имеют, так как им не выделяется процессор.
5.2. Планирование потока. Создание потока. Управление потоками
Алгоритмы планирования процессов и потоков
Слайд – Алгоритмы планирования потоков
Есть два способа реализации пакета потоков [17]:
в пространстве пользователя или на уровне пользователя (User-level threads – ULT);
в ядре или на уровне ядра (kernel-level threads – KLT).
Рассмотрим эти способы, их преимущества и недостатки.
В программе, полностью состоящей из ULT-потоков, все действия по управлению потоками выполняются самим приложением. Ядро о потоках ничего не знает и управляет обычными однопоточными процессами (рис. 5.7).
Если управление потоками происходит в пространстве пользователя, каждому процессу необходима собственная таблица потоков. Она аналогична таблице процессов с той лишь разницей, что отслеживает такие характеристики потоков, как счетчик команд, указатель вершины стека, регистры состояния и т. п. Когда поток переходит в состояние готовности или блокировки, вся информация, необходимая для повторного запуска, хранится в таблице потоков.
По умолчанию приложение в начале своей работы состоит из одного потока и его выполнение начинается как выполнение этого потока. Такое приложение вместе с составляющим его потоком размещается в одном процессе, который управляется ядром. Выполняющийся поток может породить новый поток, который будет выполняться в пределах того же процесса. Новый поток создается с помощью вызова специальной подпрограммы из библиотеки, предназначенной для работы с потоками. Передача управления этой программе происходит в результате вызова соответствующей процедуры.
Таких процедур может быть по крайней мере четыре: thread-create, thread-exit, thread-wait и thread-yield, но обычно их больше. Библиотека подпрограмм для работы с потоками создает структуру данных для нового потока, а потом передает управление одному из готовых к выполнению потоков данного процесса, руководствуясь некоторым алгоритмом планирования. Когда управление переходит к библиотечной программе, контекст текущего процесса сохраняется в таблице потоков, а когда управление возвращается к потоку, его контекст восстанавливается. Все эти события происходят в пользовательском пространстве в рамках одного процесса. Ядро даже "не подозревает" об этой деятельности и продолжает осуществлять планирование процесса как единого целого и приписывать ему единое состояние выполнения.
Использование потоков на уровне пользователя имеет следующие преимущества [17]:
высокая производительность, поскольку для управления потоками процессу не нужно переключаться в режим ядра и обратно. Процедура, сохраняющая информацию о потоке, и планировщики являются локальными процедурами, их вызов существенно более эффективен, чем вызов ядра;
имеется возможность использования различных алгоритмов планирования потоков в различных приложениях (процессах) с учетом их специфики;
использование потоков на пользовательском уровне применимо для любой операционной системы. Для их поддержки в ядро системы не требуется вносить каких-либо изменений.
Однако имеются и недостатки по сравнению с использованием потоков на уровне ядра:
в типичной ОС многие системные вызовы являются блокирующими. Когда в потоке, работающем на пользовательском уровне, выполняется системный вызов, блокируется не только этот поток, но и все потоки того процесса, к которому он относится;
в стратегии с наличием потоков только на пользовательском уровне приложение не может воспользоваться преимуществом многопроцессорной системы, так как ядро закрепляет за каждым процессом только один процессор. Поэтому несколько потоков одного и того же процесса не могут выполняться одновременно. В сущности, получается мультипрограммирование в рамках одного процесса;
при запуске одного потока ни один другой поток не будет запущен, пока первый добровольно не отдаст процессор. Внутри одного процесса нет прерываний по таймеру, в результате чего невозможно создать планировщик для поочередного выполнения потоков.
Рассмотрим теперь потоки на уровне ядра. В этом случае в области приложения система поддержки исполнения программ не нужна, нет необходимости и в таблицах потоков в каждом процессе. Вместо этого есть единая таблица потоков, отслеживающая все потоки в системе. Если потоку необходимо создать новый поток или завершить имеющийся, он выполняет запрос ядра, который создает или завершает поток, внося изменения в таблицу потоков (рис. 5.8).
Рис. 5.8. Потоки в пространстве ядра
5.3. Взаимодействие и синхронизация процессов и потоков
В мультипрограммных однопроцессорных системах процессы чередуются, обеспечивая эффективное выполнение программ. В многопроцессорных системах возможно не только чередование, но и перекрытие процессов. Обе эти технологии, которые можно рассматривать как примеры параллельных вычислений, порождают одинаковые проблемы. Выполнение процессов и потоков в мультипрограммной среде всегда имеет асинхронный характер – невозможно предсказать относительную скорость выполнения процессов. Момент прерывания потоков, время нахождения их в очередях к разделяемым ресурсам, порядок выбора потоков для выполнения – все эти события являются результатом стечения многих обстоятельств и являются случайными, это справедливо как по отношению к потокам одного процесса, выполняющим общий программный код, так и по отношению к потокам разных процессов, каждый из которых выполняет собственную программу.
Способы взаимодействия процессов (потоков) можно классифицировать по степени осведомленности одного процесса о существовании другого [10].
Процессы не осведомлены о наличии друг друга (например, процессы разных заданий одного или различных пользователей). Это независимые процессы, не предназначенные для совместной работы. Хотя эти процессы и не работают совместно, ОС должна решать вопросы конкурентного использования ресурсов. Например, два независимых приложения могут затребовать доступ к одному и тому же диску или принтеру. ОС должна регулировать такие обращения.
Процессы косвенно осведомлены о наличии друг друга (например, процессы одного задания). Эти процессы не обязательно должны быть осведомлены о наличии друг друга с точностью до идентификатора процесса, однако они разделяют доступ к некоторому объекту, например, буферу ввода-вывода, файлу или БД. Такие процессы демонстрируют сотрудничество при разделении общего объекта.
Процессы непосредственно осведомлены о наличии друг друга (например, процессы, работающие последовательно или поочередно в рамках одного задания). Такие процессы способны общаться один с другим с использованием идентификаторов процессов и изначально созданы для совместной работы. Эти процессы также демонстрируют сотрудничество при работе.
5.4. Уничтожение потока
Рассмотреть самостоятельно
5.5. Управление потоками: примеры реализаций
Планирование потоков рассмотрим на примере ОС Windows
В Windows реализована подсистема вытесняющего планирования на основе уровней приоритета. Всегда выполняется поток с наивысшим приоритетом к выполнению.
В многопроцессорных системах под Windows NT и Windows 2000 выбор потока для выполнения может быть ограничен набором процессоров, на которых он может работать. Этот метод называется привязкой к процессору (processor affinity). По умолчанию поток выполняется на любом процессоре. С помощью функций Win32 можно изменить привязку к процессорам.
Выбранный для выполнения поток работает в течение некоторого периода называемого квантом. После того, как истёк квант времени ОС будет искать другой поток с таким же уровнем приоритета или выше. Если таких нет, то ищет с меньшим приоритетом. В Windows 2000 потокам могут выделяться разные кванты времени. Поток также может не полностью использовать свой квант.
Слайд – Типичный граф состояния потока
Как только другой поток с более высоким приоритетом готов к выполнению, текущий поток вытесняется даже если его квант не истёк.
Код Windows, отвечающий за планирование реализован в ядре ОС. Этот код рассредоточен по ядру, поэтому нет единого модуля или процедуры с названием планировщик. Совокупность процедур, выполняющих планирование называется диспетчером ядра.
Диспетчер ядра инициализируется следующими событиями:
1) Поток готов к выполнению, например, он только что создан или вышел из состояния ожидания.
2) Поток прекращает выполнение, когда его квант истёк или поток завершается, или поток переходит в состояние ожидания.
3) Приоритет потока изменяется, например, в результате вызова системного сервиса.
4) Изменяется привязка к процессорам выполняемого потока.
В любом из этих четырёх случаев Windows должна определить, какой поток должен выполняться следующим.
Выбрав новый поток Windows включает CONTEXT, текущее содержание регистров процессора переписывается в структуру CONTEXT.
Планирование в Windows осуществляется на уровне потоков, то есть ОС не волнует то, какому процессу принадлежит тот или иной поток.
Пример. Если у процесса А – 12 потоков, а у В – 2 потока, и все 14 потоков имеют один и тот же приоритет, то каждый поток получит 1/14 времени процессора. Windows не будет делить поровну время процессора между двумя процессами.
Уровни приоритетов рассмотрены в теме 2.
Квант – это интервал процессорного времени, отведенный потоку для выполнения.
В Windows 2000 возможно динамическое изменение кванта времени. В ней у каждого потока своё значение кванта. Значение кванта выражается не в единицах времени, а целым числом. По умолчанию начальная величина кванта в Windows 2000 Professional Edition равна 6. В Windows 2000 Server она равна 36. Величина кванта увеличена для того, чтобы свести к минимуму переключение контекста, то есть серверные приложения пробуждаются при получении запроса клиента, и имея большой квант имеют время полностью обслужить запрос по истечению кванта времени.
Всякий раз, когда возникает прерывание системного таймера процедура обработки таймера вычитает из кванта потока величину, равную 3. Если квант закончится, инициализируется процедура обработки завершения кванта, в результате к процессору может быть подключен другой поток.
Длина временного интервала таймера зависит от аппаратной платформы и определяется не ядром, а уровнем аппаратных абстракций. В большинстве процессоров х86 временной интервал таймера равен 10 мс для однопроцессорных систем и 15 для многопроцессорных систем.
