Планирование работы мультипроцессора

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

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

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

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

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

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

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

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

Кроме того, иногда полезно планировать работу потоков, осуществляющих интенсивный обмен данными, скажем, в режиме «производитель — потребитель», не только в одно и то же время, но и близко друг к другу в пространстве. Например, они могут получить преимущество от совместного использования кэшей. Подобно этому, в NUMA- архитектурах может быть полезно дать им возможность доступа к той памяти, которая будет находиться поблизости.

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

Еще по теме Планирование работы мультипроцессора:

  1. Планирование телепередач
  2. Планирование, а не планы
  3. 11. КРИМИНАЛИСТИЧЕСКИЕ ВЕРСИИ И ПЛАНИРОВАНИЕ РАССЛЕДОВАНИЯ
  4. § 2. ПЛАНИРОВАНИЕ И СОДЕРЖАНИЕ НАБЛЮДЕНИЯ
  5. 10.2. Планирование и организация следственных действий
  6. 5.4. Планирование упражнений
  7. 5.9. Планирование социальных контактов
  8. Искусство планирования спонтанного
  9. 5.2.9. Планирование сроков достижения уже определённой цели
  10. Статья 437. Планирование, подготовка, развязывание и ведение агрессивной войны
  11. 11.3. Понятие и основные принципы планирования расследования в зависимости от исходной информации (следственной ситуации)