Планирование потоков

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

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

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


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

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

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

Если выделен квант 50 мс, а запущен поток, который блокируется через 5 мс, то очередность потоков на период продолжительностью 30 мс может быть следующей: А1, В1, А2, В2, А3, В3, что невозможно получить при таких параметрах на пользовательском уровне. Эта ситуация частично показана на рис. 2.24, б.

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

Другой важный фактор заключается в том, что потоки, реализованные на уровне пользователя, могут использовать планировщик потоков, учитывающий особенности приложения. Рассмотрим, к примеру, веб-сервер, показанный на рис. 2.6. Предположим, что рабочий поток был только что заблокирован, а поток диспетчера и два рабочих потока находятся в состоянии готовности. Какой из потоков должен быть запущен следующим? Система поддержки исполнения программ, владеющая информацией о том, чем занимаются все потоки, может без труда выбрать следующим для запуска диспетчер, чтобы тот запустил следующий рабочий процесс. Эта стратегия доводит до максимума степень параллелизма в среде, где рабочие потоки часто блокируются на дисковых операциях ввода-вывода. Когда потоки реализованы на уровне ядра, само ядро никогда не будет обладать информацией, чем занимается каждый поток (хотя им могут быть присвоены разные приоритеты). Но в целом планировщики потоков, учитывающие особенности приложений, могут лучше подстроиться под приложение, чем ядро.

2.5.

<< | >>
Источник: Э. ТАНЕНБАУМ Х. БОС. СОВРЕМЕННЫЕ ОПЕРАЦИОННЫЕ СИСТЕМ Ы 4-е ИЗДАНИЕ. 2015

Еще по теме Планирование потоков:

  1. коян: Восходящий узел - включение в общий поток; Нисходящий узел - исключение из общего потока.
  2. Планирование телепередач
  3. Планирование, а не планы
  4. 11. КРИМИНАЛИСТИЧЕСКИЕ ВЕРСИИ И ПЛАНИРОВАНИЕ РАССЛЕДОВАНИЯ
  5. § 2. ПЛАНИРОВАНИЕ И СОДЕРЖАНИЕ НАБЛЮДЕНИЯ
  6. Альбатрос (восхождение на поток)
  7. ТЕОРИЯ ПОТОКА СОЗНАНИЯ
  8. 10.2. Планирование и организация следственных действий
  9. 3.9. ПОТОК СОЗНАНИЯ
  10. ПОТОК СОЗНАНИЯ
  11. 2.2.1. Поток образов
  12. 5.4. Планирование упражнений
  13. Искусство планирования спонтанного
  14. 5.9. Планирование социальных контактов
  15. Глава 3. ОТКРОЙТЕ СВОЙ ПОТОК ОБРАЗОВ
  16. 12.2.1. Групповой поток образов
  17. 5.2.9. Планирование сроков достижения уже определённой цели
  18. МИХАЙ ЧИКСЕНТМИХАЙИ. В ПОИСКАХ ПОТОКА, 2015
  19. 13.5.1. Игра в поток образов