- •Модуль 4 Вариант 1
- •1. Опишите подход к планированию в мультипроцессорах посредством разделения времени. В чем суть единой структуры данных для планирования, каковы достоинства и недостатки.
- •2. В чем суть механизма умного планирования, приоритетного планирования, родственного планирования, двухуровневого планирования.
- •3. Опишите подход функционирования ос на каждом cpu - метод персональной копии. Дайте графическую интерпретацию и основные замечания. В чем состоят достоинства и недостатки.
- •4. Организация коллективных операций в mpi.
- •Вариант 2
- •1. Опишите подход к функционированию ос на мультипроцессорах – персональная копия ос лишь cpu-хозяину, остальные – cpu-подчиненные.
- •3. Опишите подход к планированию в мультипроцессорах посредством совместного использования адресного пространства.
- •Вариант 4
- •Модуль 5 Вариант 1
- •Модель операционной системы
- •3 Вариант
- •1) Понятие масштабируемости. Особенности многопроцессорной Windows.
- •2) Графическая интерпретация этапов создания процесса в Windows
- •3) Основные функции Win32 api по работе с потоками
- •4) Функции Win32 api для работы с основными сервисами диспетчера памяти.
- •5) Защита объектов и протоколирование обращений к ним. Олицетворение: описание, назначение
- •6) Драйверы устройств. Типы драйверов устройств: пользовательский режим и режим ядра. Wdm-драйверы. Многоуровневые драйверы.
- •7) Пространство имен томов. Диспетчер монтирования. Точки монтирования. Монтирование томов.
- •8) Схема взаимодействия компонентов фс при вводе-выводе. Явный файловый ввод- вывод.
- •4 Вариант
- •1. Ключевые подсистемы ос Windows и их описание.
- •2. Этапы создания процесса.
- •3. Этапы создания потока в Windows.
- •5 Вариант
- •6 Вариант
- •Вариант 2
- •3. Особенности реализации потоков в Linux. Системный вызов clone.
- •Некоторые системные вызовы, относящиеся к безопасности
- •Вариант 5
- •Основные вызовы стандарта posix для управления терминалом
- •Вариант 6
- •Алгоритмы замещения страниц
Вариант 4
1. Механизм синхронизации в мультипроцессорах посредством мьютекс-протокола. Взаимное исключение.
Если процесс на однопроцессорной системе обращается к ресурсу, который требует доступа к некой критической таблице, программа ядра может просто запретить прерывания, прежде чем обратиться к таблице. Однако на мультипроцессоре запрет прерывания повлияет только на один CPU, выполнивший команду запрета прерываний. Остальные CPU продолжат свою работу и смогут получить доступ к критической таблице. Требуется специальный мьютекс-протокол, который будет выполняться всеми CPU, чтобы гарантировать работу взаимного исключения.
Сутью мьютекс-протокола является команда CPU, позволяющая исследовать и изменить слово в памяти за одну операцию. Эта команда считывает слово памяти в регистр CPU. Одновременно она записывает 1 (или другое ненулевое значение) в слово памяти. Конечно, для выполнения операций чтения и записи памяти требуется два цикла шины. На однопроцессорной машине, поскольку одна команда CPU не может быть прервана на полпути, команда TSL работает должным образом.
Для разрешения этой проблемы команда TSL сначала должна блокировать шину посредством команды LOCK, не допуская обращения к ней других CPU, затем выполнить оба обращения к памяти, после чего разблокировать шину. Как правило, посреством этой команды сначала выполняется обычный запрос шины по стандартному протоколу, затем устанавливается в 1 некая специальная линия шины. Пока эта линия шины установлена в 1, никакой другой CPU не может получить к ней доступ. Такая команда может быть выполнена только на шине, у которой есть необходимые специальные линии и (аппаратный) протокол для их использования. Для чисто программной синхронизации был разработан протокол Петерсона.
2. Кеширование и проблема конкуренции за шину. Решение проблемы кеширования: итерация пробного чтения, двоичный экспоненциальный откат, опрос собственной переменной блокировки.
TSL-способ реализации взаимного исключения использует спин-блокировку, так как запрашивающий CPU находится в цикле опроса блокировки с максимальной скоростью. Этот метод является не только тратой времени запрашивающего CPU, но он также может накладывать значительную нагрузку на шину или память, а следственно тормозить всю систему.
На первый взгляд может показаться, что наличие кэширования должно устранить проблему конкуренции за шину, но это не так. Кэш оперирует блоками по 32 или 64 байт. Слова, окружающие слово блокировки, нужны CPU, удерживающему это слово. Поскольку команда TSL требует монопольный доступ к блоку кэша, содержащему слово блокировки. Как только CPU изменит слово, соседнее с блокировкой, блок кэша перемещается на его машину. В результате весь блок кэша, мотается взад-вперед от CPU, удерживающего блокировку, к CPU, пытающемуся ее получить.
Проблему можно было бы решить, если бы удалось избавиться от всех операций записи, вызванных командой TSL запрашивающей стороны:
Это можно сделать, если запрашивающая сторона сначала будет выполнять простую итерацию чтения, чтобы убедиться, что мьютекс свободен. В результате большинство операций опроса представляют собой операции чтения, а не операции записи.
Другой способ снижения шинного трафика заключается в использовании алгоритма двоичного экспоненциального отката. Вместо постоянного опроса, между опросами может быть вставлен цикл задержки. Если мьютекс занят, задержка удваивается, учетверяется и т. д. до некоторого максимального уровня. Используется в сети Интернет.
Еще более удачная идея заключается в том, чтобы каждому CPU, желающему заполучить мьютекс, позволить опрашивать свою собственную переменную блокировки. CPU, которому не удается заполучить мьютекс, захватывает переменную блокировки и присоединяется к концу списка CPU, ожидающих освобождения мьютекса.
3. Опишите механизм бригадного планирования – планирование во времени и пространстве, в чем его достоинства и недостатки.
Очевидное преимущество разделения пространства заключается в устранении многозадачности, что снижает накладные расходы по переключению контекста. Однако ее недостаток состоит в потерях времени при блокировке CPU.
Решением данной проблемы является так называемое бригадное планирование, представляющее собой развитие идеи совместного планирования. Бригадное планирование состоит из трех частей:
Группы связанных потоков планируются как одно целое, бригада.
Все члены бригады запускаются одновременно, на разных CPU с разделением времени.
Все члены бригады начинают и завершают свои временные интервалы вместе.
Бригадное планирование работает благодаря синхронности работы всех CPU. Это значит, что время разделяется на дискретные кванты. В начале каждого нового кванта все CPU перепланируются заново, и на каждом CPU запускается новый поток. В начале следующего кванта опять принимается решение о планировании. В середине кванта планирование не выполняется. Если какой-либо поток блокируется, его CPU простаивает до конца кванта времени. Идея бригадного планирования состоит в том, чтобы все потоки процесса работали по возможности вместе, так, что если один из них посылает сообщение другому потоку, то второй поток получает сообщение практически мгновенно и может так же быстро на него ответить.
4. Балансировка нагрузки посредством распределенного эвристического алгоритма (с инициативой отправителя, так и получателя).
Балансировка нагрузки — метод распределения заданий между несколькими сетевыми устройствами с целью оптимизации использования ресурсов, сокращения времени обслуживания запросов, горизонтального масштабирования кластера, а также обеспечения отказоустойчивости.
Распределенный эвристический алгоритм, инициируемый отправителем
При использовании одного алгоритма процесс работает на узле, который его создал, если только этот узел не перегружен. Перегрузка может оцениваться по числу процессов, их суммарной нагрузке на CPU или по какому-либо еще параметру. Если узел оказывается перегружен, он выбирает случайным образом другой узел и запрашивает у него данные о его загрузке. Если загрузка данного узла оказывается ниже определенного уровня, новый процесс отправляется туда.
Распределенный эвристический алгоритм, инициируемый получателем
Согласно этому алгоритму, когда процесс завершает свою работу, система проверяет, достаточно ли у нее работы. Если нет, она произвольным образом выбирает какую-нибудь машину и просит у нее работу. Если этой машине нечего предложить, то опрашивается вторая, а затем третья машина. Такой подход не создает лишней нагрузки от опросов в критический период, когда все машины загружены.
Вариант 5
В чем состоит суть проблема ожидания в цикле либо переключение, поиск компромисса: простое ожидание, спин-блокировка, учет предыдущих интервалов ожидания.
CPU, которому требуется мьютекс, просто ждет, пока тот не освободится, опрашивая его состояние постоянно или периодически, либо присоединяясь к списку ожидающих CPU. Однако в некоторых случаях у CPU может переключиться на другой поток. Вопрос принятия решения о том, ждать или переключиться на другой поток, являлся предметом многочисленных исследований.
Если допустить, что оба варианта выполнимы, возникает следующая ситуация. Циклический опрос напрямую расходует время CPU. Периодическая проверка состояния мьютекса не является продуктивной работой. Переключение процессов, однако, также расходует циклы CPU, так как для этого требуется сохранить текущее состояние потока, получить мьютекс списка свободных процессов, выбрать из этого списка поток, загрузить его состояние и передать ему управление. Более того, кэш CPU будет содержать не те блоки, поэтому после переключения потоков возможно много промахов кэша. Также вероятны ошибки TLB. Наконец, потребуется переключение обратно на исходный поток.
Проблема в том, что длительность нахождения процессов в критических областях может варьироваться в широких пределах, поэтому выбор верного решения непрост:
1. Всегда использовать циклический опрос.
2. Использование только переключений.
3. Каждый раз принимать отдельное решение.
В момент принятия решения не известно, что лучше — переключаться или ждать, но в любой системе можно отследить активность процессов и затем проанализировать ее в автономном режиме. При этом можно сказать, какое решение было бы лучшим в том или ином случае и сколько времени CPU было потрачено.
На практике используется модель, в которой поток, не заполучивший мьютекс, какое-то время опрашивает состояние мьютекса в цикле (спин-блокировка). Если пороговое значение времени ожидания превышается, он переключается. В некоторых случаях пороговое значение фиксировано, как правило, оно равно известному времени, требующемуся на переключение на другой поток и обратно.
2.Опишите программный интерфейс OpenMP и принципы распараллеливания в приложениях с его помощью.
OpenMP (Open specifications for Multi–Processing) – стандарт для написания параллельных программ для многопроцессорных вычислительных систем с общей оперативной памятью. Программа представляется как набор нитей (threads), объединённых общей памятью, где проблема синхронизации решается введением критических секций и мониторов. OpenMP используется модель параллельного выполнения “ветвление-слияние” (fork-join). Программа начинается выполнением одной нити, называемой начальной (initial) нитью. Начальная нить выполняется последовательно. Когда нить достигает директивы parallel она создает команду нитей, состоящую из неё самой и нуля или более дополнительных нитей, и становится хозяйкой (master) созданной команды. Все члены команды исполняют код структурной области, связанной с директивой parallel (параллельной области). В конце параллельной области размещается неявный барьер. Только нить(master) продолжает выполнение после завершения параллельной области.
В программе может находится любое количество директив parallel. Параллельные области могут быть вложены друг в друга.
Команда нитей, встретившая конструкцию распределения работы, разделяет работу заданную этой конструкцией между нитями команды, и эта работа выполняется нитями совместно, вместо того чтобы выполняться полностью каждой нитью. После конструкции распределения работы все нити продолжают выполнение кода параллельной области.
Конструкции синхронизации и библиотечные подпрограммы позволяют согласовывать выполнение нитей и доступ к данным в параллельных областях. Отметьте, что нет гарантий синхронного доступа к файлам при выполнении ввода/вывода из разных нитей, поэтому синхронизация в этом случае возлагается на программиста.
3.Механизм передачи сообщений - вызов удаленных процедур. Маршалинг данных.
Этот метод межпроцессного взаимодействия использует два примитива: send и receive, которые скорее являются системными вызовами, чем структурными компонентами языка (что отличает их от мониторов и делает похожим на семафоры). Поэтому, их легко можно поместить в библиотечные процедуры, например:
send(destination. &message);
receive(source, &message);
Первый запрос посылает сообщение заданному адресату, а второй – получает сообщение от указанного источника. Если сообщения нет, второй запрос блокируется до поступления сообщения либо немедленно возвращает код ошибки.
Разработка систем передачи сообщений
С системами передачи сообщений связано большое количество сложных проблем и конструктивных вопросов, которых не возникает в случае семафоров и мониторов. Особенно много сложностей появляется в случае взаимодействия процессов, происходящих на различных компьютерах, соединенных сетью. Сообщение может потеряться в сети. Чтобы избежать потери, отправитель и получатель договариваются, что при получении сообщения получатель посылает обратно подтверждение приема сообщения.
Для систем обмена сообщениями также важен вопрос названий процессов. Необходимо однозначно определять процесс, указанный в запросе send или receive. Кроме того,встает вопрос аутентификации: каким образом клиент может определить, что он взаимодействует с настоящим файловым сервером, а не с самозванцем?
Помимо этого, существуют конструктивные проблемы, существенные при расположении отправителя и получателя на одном компьютере. Одной из таких проблем является производительность. Копирование сообщений из одного процесса в другой происходит гораздо медленнее, чем операция на семафоре или вход в монитор.
Маршалинг даных – процесс преобразования информации, хранящейся в оперативной памяти, в формат, пригодный для хранения или передачи. Обычно применяется тогда, когда информацию необходимо передавать между различными частями одной программы или от одной программы к другой.
4.Возможные проблемы в процессе реализации вызова удаленных процедур.
Решение проблемы производителя и потребителя с передачей сообщений и без использования разделенной памяти. Как только у производителя оказывается элемент данных, который он может предоставить потребителю, он берет пустое сообщение и отсылает назад полное.Таким образом, общее число сообщений в системе постоянно и их можно хранить в заранее заданном участке памяти.
Если производитель работает быстрее, чем потребитель, все сообщения будут ожидать потребителя в заполненном виде. Если потребитель работает быстрее, ситуация инвертируется: все сообщения будут пустыми, а потребитель будет блокирован в ожидании полного сообщения.
Другой подход состоит в использовании новой структуры данных, называемой почтовым ящиком. Почтовый ящик — это буфер для определенного количества сообщений, тип которых задается при создании ящика. При использовании почтовых ящиков в качестве параметров адреса send и receive задаются почтовые ящики, а не процессы. Если процесс пытается послать сообщение в полный почтовый ящик, ему приходится подождать, пока хотя бы одно сообщение не будет удалено из ящика. С использованием почтовых ящиков метод буферизации очевиден: в почтовом ящике получателя хранятся сообщения, которые были посланы процессу-получателю, но еще не получены.
Вариант 6.
1. Вопросы планирования: какой процесс запустить следующим, зависимость процессов между собой.
Планирование процессов в ОС это процесс выбора – кто будет исполняться следующим и как долго это будет исполняться.
Существуют следующие алгоритмы планирования процессов:
FIFO
Кратчайшая работа следующей
Round-robin
Многоуровневая очередь
Многоуровневая очередь с обратной связью
FIFO (First In, First Out) — способ организации и манипулирования данными относительно времени и приоритетов. Техническая обработка очереди по принципу: «первым пришёл — первым обслужен» (ПППО). Тот, кто приходит первым, тот и обслуживается первым, пришедший следующим ждёт, пока обслуживание первого не будет закончено, и так далее.
Кратчайшая работа следующей. Суть процесса — следующим запланировать тот процесс, который требует наименьшего времени для своего выполнения, т.е. процесс имеющий самое короткое время обработки. Однако, нужно оценивать требуемое время обработки для каждого процесса.
Планирование с приоритетами. Каждому процессу сопоставляется некоторое число, которое характеризует, определяет приоритет этого процесса. Чем меньше это число, тем выше приоритет. Время ЦП выделяется процессу с наивысшим приоритетом. Процесс с низким приоритетом может вообще никогда не выполниться, до него не дойдет очередь.
Round-robin — алгоритм распределения нагрузки распределённой вычислительной системы методом перебора и упорядочения её элементов по круговому циклу.
Многоуровневые очереди. Выделяется несколько разных очередей, например:
Очередь интерактивных процессов;
Очередь фоновых процессов.
У каждой очереди сопоставляется свой алгоритм планирования, таким образом имеем некий «баланс сил»:
у интерактивных процессов RR;
у фоновых — FIFO.
Но в случае многоуровневых очередей нужно планирование не просто внутри каждой очереди, но и планирование между очередями. Получается «накрученный» планировщик.
Многоуровневая очередь с обратной связью. Планирование на основе затраченного времени, если процесс затратил определенный квант времени, то он помещается в определенную очередь – динамически перепланируются очереди.
Многоуровневая очередь с обратной связью
Если он выполнился достаточно быстро, то он попадает в первую очередь «быстрых» процессов.
Если он средний по времени выполнения, то в среднюю.
Если он требует много времени вычислительных ресурсов, то он помещается в последнюю очередь FIFO.
За счет этого процессы постоянно перемещаются между очередями, таким образом заранее не нужно смотреть, куда помещать процесс и сопоставлять ему какое-то свойство.
2. Блокирующие и неблокирующие вызовы. Решение проблемы неблокирующих вызовов.
Системные вызовы Интерфейс между ОС и программами пользователя определяется набором системных вызовов (СВ), предоставляемых ОС. Системные вызовы, доступные в интерфейсе, меняются от одной ОС к другой. У большинства современных ОС есть СВ, выполняющие те же самые функции, хотя детали могут быть различны. Так фактический механизм обращения к системным функциям является в высокой степени машинно-зависимым и часто должен реализовываться на ассемблере, существуют библиотеки процедур, делающие возможным обращение к системным процедурам из программ на С и других языках с тем же успехом. Любой компьютер с одним процессором в каждый конкретный момент времени может выполнить только одну команду. Если процесс выполняет программу пользователя в пользовательском режиме и нуждается в системной службе, например чтении данных из файла, он должен выполнить прерывание или команду СВ для передачи управления ОС. СВ может блокировать вызвавшую его процедуру, препятствуя продолжению ее работы. Например, если она пытается прочесть что-то с клавиатуры, а там еще ничего не набрано, процедура должна быть блокирована. В этом случае ОС ищет процесс, который может быть запущен следующим. Позже, когда нужное устройство станет доступно, система вспомнит о блокированном процессе. В ОС присутствуют СВ для управления всеми ресурсами ОС, например: Процессами и потоками. Памятью. Файловой системой, в частности файлами и каталогами. Вводом-выводом. И т.д.
3. Опишите механизм MPI и принципы построения распределенных приложений с его помощью.
Интерфейс на основе передачи сообщений (MPI - Message Passing Interface) является стандартной моделью программирования для разработки приложений с явным параллелизмом (т.е., параллельные части программы определяет программист), в которых параллельные процессы взаимодействуют между собой путем передачи сообщений.
Операции передачи данных в MPI типа "точка-точка" представляют собой передачу сообщений между, в точности, двумя MPI-процессами. Один процесс, при этом, выполняет команду Send (послать), тогда как другой процесс выполняет команду Receive (принять). Выполнение команд Send и Receive осуществляется посредством вызова соответствующих MPI-функций, которые имеют различные типы, или, другими словами, различное назначение:
Блокирующий Send / блокирующий Receive
Неблокирующий Send / неблокирующий Receive
Синхронный Send
Буферированный Send
Комбинированный Send / Receive
Send по готовности ( "ready" Send ).
Основные особенности и отличия радиовещательных (коллективных) обменов данными от обменов типа "точка-точка" состоят в следующем:
принимают и/или передают данные одновременно все процессы группы для указываемого коммуникатора;
радиовещательная (коллективная) функция выполняет одновременно и прием, и передачу данных, а потому она имеет параметры, часть из которых относится к приему, а часть - к передаче данных;
как правило, значения всех параметров (за исключением адресов буферов) должны быть идентичны во всех процессах;
коллективные операции являются блокирующими;
коллективные операции могут использоваться только для встроенных (predefined) MPI-типов данных, но не могут использоваться для производных (derived) MPI- типов данных.
4. Балансировка нагрузки посредством алгоритма торгов.
Данный класс алгоритмов пытается переделать компьютерную систему в нечто похожее на миниатюрную экономику, с продавцами и покупателями услуг и ценами, спросом и предложением. Главную роль в экономике играют процессы, которые должны покупать время CPU для выполнения работы.
Когда процесс хочет запустить дочерний процесс, он ищет узел, предлагает нужны ему услуги. затем он определяет набор узлов, услугами которых он может воспользоваться. Из этого набора процесс выбирает лучшего кандидата (самого дешевого, быстрого), и посылает это первом кандидату.
Процессоры собирают заказы, им поступают, и делают свой выбор, останавливаясь на заказе с наибольшей цене. Победители и побежденные информируются о сделанном выборе. выигравший процесс выполняется. Затем обновляется опубликована цена сервера.
