Выгоды многозадачности и многопроцессности

Повторная входимость.

Здесь возникает вопрос о реeнтерабильности процессов.

MS Windows использует для запоминания системные стеки при 21h.

34h – если флаг критичности не установлен, то все нормально, т.е. повторная входимость доступна; если установлен, то лучше туда не входить; а если установлен флаг занятости, тогда доступны функции DOS 0¸0ch:

mov ah, 34h

int 21h

; ES:BX ® флаг занятости

; ES:[BX-1] ® флаг критичности

Примеры ассемблерных вставок:

; сохранение векторов прерываний

; в сегменте данных

keep_CSI dw?

keep_IPI dw?

; в кодовом сегменте

CLI

mov ah, 35h

mov al, I ; в al – номер прерывания

int 21h ; ES:BX

mov keep_CSI, ES

mov keep_IPI, BX

STI

; установка обработчика прерывания

; обр_прерыв находится в отдельном месте

push ds

mov dx, offset обр_прерыв

mov ax, seg обр_прерыв

mov ds, ax ; DS:DX

mov ah, 25h

mov al, номер_прерыв

int 21h

pop ds

Исключение:

Это тоже прерывание, но если прерывание работает по внешним причинам, то исключение – по внутренним. После обработки исключения процесс может остановиться.

Исключение – это, как правило, обработка ошибок.

Организация параллельного (псевдопараллельного)
режима на уровне ОС.

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

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

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

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

В системах реального времени возможность заниматься каким-то полезным делом во время ожидания внешнего события часто оказывается жизненно необходимой.

Теоретически можно возложить задачу распараллеливания на пользовательскую программу - так поступают некоторые разработчики программ реального времени для MS DOS или в некоторых кросс-системах.

Однако многопроцессность создает ряд специфических проблем, и оказывается целесообразным реализовать решения этих проблем один раз, собрать код, решающий их, в единый модуль и объявить этот модуль ядром ОС. Именно таким образом построено ядро систем RT-11, OS-9 и ОС, базирующихся на технологии микроядра (microkernel) - QNX, UNIX System V R4, HURD.

В других ОС в ядро помещен также код, занимающийся работой с внешними устройствами, и даже менеджеры файловых систем. Такие системы сейчас называются «монолитными». Выгоды и недостатки обоих решений будут обсуждаться ниже. 4.2. Проблемы при параллельной работе

Первой из проблем является проблема разделения ресурсов. Действительно, представим себе две программы, пытающиеся печатать что-то на одном принтере. Если они будут делать это произвольным образом, их вывод на бумаге будет перемешан и скорее всего окажется совершенно нечитаемым. Одним из разумных решений может быть монопольный захват принтера одной из программ. При этом другая программа будет вынуждена ждать, пока принтер не освободится. Значит, нужны средства для захвата ресурсов и ожидания их освобождения¹⁷. Другая проблема - это проблема реентерабельности (reenterability - повтоpной входимости, от re-enter) разделяемых программ.

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

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

Легко понять, что программы, управляющие внешними устройствами или файловыми системами и вообще работающие с разделяемыми объектами, не могут быть реентерабельными.

Во многих случаях оказывается выгодно рассматривать нереентерабельную программу как разделяемый ресурс и распределять доступ к нему теми же способами, что и к принтеру. Так поступает большинство известных авторам средств организации параллельной работы под MS DOS. Таким же образом микроядро организует доступ пользовательских программ к модулям ОС.

Очень широкий класс проблем - проблемы синхронизации, возникающие при попытках организовать взаимодействие нескольких программ.

Первая, самая простая из них, состоит в вопросе - если одна задача производит данные, а вторая их потребляет, то как задача-потребитель узнает, что готова очередная порция данных? Или, что еще интереснее, как она узнает, что очередная порция данных еще не готова? Типичный случай такого взаимодействия - асинхронное чтение с диска, когда программа дает дисковому драйверу запрос: «читай с такого-то сектора в такой-то блок памяти», и продолжает заниматься своими делами. Это режим работы, поддерживаемый всеми ОС линии RT-11 - RSX-11 - VAX/VMS - OpenVMS и многими системами реального времени.

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

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

Процесс – подпрограмма, поступившая на уровень ядра ОС.

2 аспекта процесса:

а) теоретический;

б) практический.

а) Первый аспект – по Хоару: процесс+<событие>®процесс+<событие>®…;

По Крыковяку процесс – некоторая траектория: