Bilet 28

Билет 28.
1. Потоки в Windows и UNIX.
Windows:
В Windows именно потоки являются объектами диспетчеризации, соответственно основной механизм работы с потоками процесса - это управление потоками в пространстве ядра. Основные структуры:
* Блок потока исполнительной системы ETHREAD
o блок потока ядра KTHREAD
o время создания и завершения потока
o идентификатор процесса и указатель на блок EPROCESS процесса
o адрес стартовой процедуры потока
o идентификатор и адрес сообщения, ожидаемого потоком
o список необработанных запросов на ввод-вывод
* блок потока ядра KTHREAD
o заголовок диспетчера
o суммарное время потока в пользовательском режиме и в режиме ядра
o указатель на таблицу системных сервисов
o базовый и текущий приоритеты
o значение кванта
o маска привязки к процессорам
o счетчики числа замораживаний и приостановок
o 4 встроенных блока ожидания
Windows поддерживает управление потоками и на уровне пользователя (облегченные потоки, fiber, волокно). Соответственно ядру они невидимы.
* ConvertThreadToFiber - преобразование потока в облегченный
* CreateFiber - создание нового облегченного потока
* GetFiberData - получение данных облегченного потока
* GetCurrentFiber - возвращает дескриптор облегченного потока
* DeleteFiber - уничтожает облегченный поток и его данные
* SwitchToFiber - выбор волокна на выполнение. Волокно не выполняется и не диспетчеризируется, пока не будет выбрано на выполнение программно с помощью данной функции. Работает до завершения или до переключения на другое волокно с помощью этой же функции
UNIX:
Существует несколько библиотек для поддержки с потоков процесса в пространстве пользователя. Стандартом POSIX определена библиотека pthreads. Такая библиотека может быть реализована и для систем, не имеющих специальной поддержки потоков. Тогда функции библиотеки работают как мини-ядра, храня и обрабатывая всю информацию о потоках
Ряд современных систем поддерживает потоки процесса в пространстве ядра (LWP). В этом случае библиотека может быть реализована разными способами.
* Каждый поток может быть реализован как LWP o библиотека в этом случае максимально упрощается, поскольку управление потоками и хранение информации обеспечивает ядро
o требуемое количество ресурсов ядра значительно увеличивается
o ядро участвует во всех операциях планирования и синхронизации потоков
* Библиотека создает для каждого процесса набор LWP и мультиплексирует в него прикладные потоки
o нет простого способа гарантировать предоставление ресурсов конкретному потоку
o требует меньшего количества ресурсов ядра
o Поток называется свободным, если LWP связывается c ним одним. Потоки называется несвязанными, если они разделяют общий набор LWP
2. Механизмы взаимного исключения.
* Ресурсы, не допускающие одновременного использования, называются критическими
* Фрагмент кода, в котором происходит обращение к критическим ресурсам, называется критической областью или критической секцией * Механизм, не позволяющий процессам обращаться к критическому ресурсу одновременно, называется механизмом взаимного исключения
Решение задачи взаимного исключения в том, чтобы организовать доступ к критическому ресурсу таким образом, что в текущий момент времени только одному процессу разрешается находиться в критической области.
В общем случае структура процесса, участвующего во взаимодействии, может быть представлена следующим образом:
Здесь под remainder section понимаются все атомарные операции, не входящие в критическую секцию.
Если один из процессов владеет критическим ресурсом, остальные процессы должны получить отказ и ждать освобождения ресурса. При этом, если процессы выполняют операции, не приводящие к конфликтам, т.е. вне критической области, они должны иметь возможность параллельной работы. Если процесс, имеющий доступ к критическому ресурсу, выходит из своей критической области, доступ должен быть передан другому процессу, ожидающему доступа
Условия корректной организации взаимного исключения:
* в любой момент времени только один процесс должен находиться в своей критической области (условие взаимного исключения);
* - никакой процесс, находящийся вне своей критической секции, не должен влиять на выполнение других процессов, ожидающих входа в критические область, т.е. он не должен блокировать критическую область другого процесса; * если несколько процессов одновременно хотят войти в критическую область, то принятие решения, кому предоставить доступ, не должно откладываться бесконечно долго (условие прогресса)
* - ни один процесс не должен ждать бесконечно долго вхождения в критическую область и, следовательно, ни один процесс не должен находиться в критической секции бесконечно долго; (условие ограниченного ожидания)
* - не должно быть никаких предположений о скорости или количестве процессов 3. Шлюзы вызова.
* В каждый момент времени программа находится на одном из имеющихся 4 уровней защиты, что отмечается 2 битовым полем в регистре слова состояния программы (PSW)
* Каждый сегмент системы также имеет свой уровень
o 3 - это пользовательские программы
o 2 - библиотеки совместного доступа
o 1 - системные узлы o 0 - ядро
* Разрешен доступ к данным на своем и более высоких уровнях
* При попытке доступа к данным низкого уровня вызываются прерывания
* Вызов процедур как высокого, так и низкого уровня допускается, однако для этого инструкция CALL должна содержать селектор вместо адреса
* Этот селектор определяет дескриптор - шлюз вызова (call gate), который передает адрес вызываемой процедуры
* Попасть в середину произвольного сегмента кода другого уровня невозможно
* Могут использоваться только стандартные точки входа
* Подобный механизм используют программные и аппаратные прерывания
* Они обращаются к дескрипторам, а не к абсолютным адресам, которые указывают на определенные процедуры
* Поле тип дескриптора позволяет различить программные сегменты, сегменты данных и различные виды шлюзов
4. Совместно используемые файлы, символьное связывание.
Часто удобно, чтобы один и тот же физический файл содержался в разных каталогах. В этом случае между каталогом и совместно используемым файлом устанавливается связь. Сама файловая система представляет теперь не дерево, а ориентированный ациклический граф.
Такая схема создает новые проблемы. Если в каталоге содержать указатели на блоки файла, то при изменении файла из одного каталога, соответствующая ему запись другого каталога не будет содержать измененной цепочки блоков.
Вариант решения - содержать указатели на блоки файла в особой структуре, а в каталоге содержать только ссылку на эту структуру (жесткая ссылка)
* В этом случае даже при перемещении файла (но не i-узла) все связи останутся действующими
* Если файл существует в нескольких каталогах, то при удалении его из одного каталога, ОС не может найти все связи, поэтому может только удалить запись в одном каталоге, оставив и сам файл и записи других каталогов, ему соответствующих, уменьшая счетчик связей
Второй вариант - при создании связи, во втором каталоге создается новый файл типа связь (link). Он просто содержит путь к файлу, с которым он связан (символьное связывание)
* Символьные связи можно использовать для ссылок на файлы, расположенные на удаленных машинах
* Увеличивается время поиска - поскольку сначала находится лишь файл связи, а затем, взяв из него правильный путь, ищется собственно файл
* При перемещении файла ссылка становится нерелевантной, т.е. связь теряется