Билет 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). Он просто содержит путь к файлу, с которым он связан (символьное связывание) * Символьные связи можно использовать для ссылок на файлы, расположенные на удаленных машинах * Увеличивается время поиска - поскольку сначала находится лишь файл связи, а затем, взяв из него правильный путь, ищется собственно файл * При перемещении файла ссылка становится нерелевантной, т.е. связь теряется
1/--страниц