Лекция 7

понедельник, 16 апреля 2012 г.

Диспетчер прерываний – существует в нем понятие маскирование – это временный отказ от обработки прерываний любого класса независимо от уровня прерывания, последовательность действий при обработки прерываний:

1. При возникновении сигнала при обработке сигнала управление передаётся диспетчеру.

2. Диспетчер определяет тип и класс прерываний.

3. Диспетчеру необходимо определить приоритет прерывания

   1. В случаи если прерывание запрещено процессор не осуществляет данное прерывание и продолжает выполнение потока

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

4. Восстановление контекста данного потока или переход к другому обработчику прерываний.

Для эффективной работы прерываний в ядре ОС всегда должен находится диспетчер прерываний, его основной целью является:

1. Обеспечивает работы диспетчера прерываний.

2. Образование очередей обработчика прерываний по аналогии с процессом.

Синхронизации процессов и потоков

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

Во многих ОС эти средства называются Inter Process Communication (IPC). Вып потока в мульти прог среде всегда имеет асинхронный характер.

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

Моменты прерывания потоков, время нахождения их в очереди(к разным ресурсам), порядок выбора потоков для выполнения – все эти события являются результатом стечения многих обстоятельств и могут быть интерпретированы как случайные.

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

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

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

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

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

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

Этапы алгоритма

1. Считать из файла базу данных в буфер, запись о клиенте с заданным идентификатором.

2. Для потока а) внести новое значение в поле заказ, а для потока б) внести новое значение в поле оплаты.

3. Вернуть модифицированную запись в файл оплаты.

Обозначим соответствующие шаги для потока а1, а2, … б1, б2 … предположим что в некоторый момент поток а) обновляет поле заказ записи о клиенте «Н» для этого он считывает запись в свой буфер шаг а1, модифицирует значение в поле заказ шаг а2 но внести изменение в базу данных шаг а3 не успевает. Так как его выполнение прерывается в следствии завершения кванта времени.

Так же предположим что потоку б) требовалось внести данные о клиенте «Н» когда приходит очередь потока б) он успевает считать запись в свой буфер шаг б1, выполнить обновление поля оплата шаг б2, и прерывается при этом заметим что в буфере у потока б) находиться запись о клиенте «Н» в котором поле заказ имеет все ещё имеет низменное значение. Когда в очередной раз управление будет передано значение в поток а) он запишет в запись о клиенте «Н» модифицированное значение. После заверш а) и активизации б) в базу данных поверх обновленной записи о клиенте «Н» будет записана обновленное значение в поле оплата но старое значение в поле заказ шаг б3 выполниться но снова измениться поле заказ.

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