Симметричные мультипроцессоры

Асимметрия модели «главный — подчиненный» устраняется в нашей третьей модели — симметричных мультипроцессорах (Symmetric MultiProcessor (SMP)). В памяти присутствует только одна копия операционной системы, но ее может запустить любой центральный процессор.
При осуществлении системного вызова центральный процессор, на котором произошел системный вызов, переходит в режим ядра и обрабатывает этот системный вызов. Модель SMP показана на рис. 8.9.

Рис. 8.9. Мультипроцессорная модель SMP


В этой модели баланс процессов и памяти осуществляется в динамическом режиме, поскольку используется только один набор таблиц операционной системы. Узкое место, связанное с главным центральным процессором, за неимением такового также отсутствует, но возникают новые проблемы. В частности, если два или более центральных процессора запускают код операционной системы в одно и то же время, может произойти авария. Представьте, что два центральных процессора одновременно выбирают для работы один и тот же процесс или требуют одну и ту же свободную страницу памяти. Простейший способ обхода этих проблем заключается в связывании с каждой операционной системой мьютекса (то есть блокировки), что превращает всю систему в одну большую критическую область. Когда центральному процессору требуется запустить код, он в первую очередь должен получить мьютекс. Если мьютекс заблокирован, процессор просто переходит в режим ожидания. Таким образом, в любой момент времени выполнять код операционной системы может любой, но только один центральный процессор. Такой подход носит название большой блокировки ядра (big kernel lock).

Эта модель работает не намного лучше модели «главный — подчиненный». Предположим еще раз, что 10 % всего рабочего времени тратится на выполнение кода операционной системы. Если используются 20 центральных процессоров, то из них может выстроиться длинная очередь ожидающих доступа к коду операционной системы. К счастью, улучшить ситуацию довольно просто. Многие части операционной системы независимы друг от друга. Например, если один центральный процессор запустит планировщик, другой в это же время займется обработкой системного вызова, связанного с файлом, а третий параллельно с этим будет обрабатывать ошибку отсутствия страницы, то проблем не возникнет.

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

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

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

Более того, нужно приложить массу усилий, чтобы избежать взаимных блокировок. Если коду сразу в двух критических областях нужны таблица А и таблица В и один из фрагментов кода первым затребовал А, а другой первым затребовал В, то рано или поздно произойдет взаимная блокировка и никто не поймет почему. Теоретически всем таблицам можно присвоить целочисленное значение, и программный код во всех критических областях может быть написан с учетом требования запроса таблиц по порядку возрастания их номеров. Эта стратегия позволит избежать взаимных блокировок, но потребует от программиста тщательно взвесить, какие таблицы кодом каких критических областей будут востребованы, и обеспечить выдачу запросов в правильном порядке.

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

8.1.3.

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

Еще по теме Симметричные мультипроцессоры:

  1. Симметричные фигуры
  2. Анализ завершенности и симметричности мандалы
  3. Несимметричная мандала
  4. Схема «Процедуры комфортизации».
  5. Схема «Процедуры комфортизации».
  6. ПРЕГНАНТНОСТЬ
  7. Завершенная мандала
  8. Наружный ход
  9. Процесс раскрытия.
  10. 9.13. Передне-срединный канал, VC (фр.), круглосуточно, канал "инь"
  11. 7. Анализ мандалы
  12. II. 2. 3. Раздвоение единого.