- •Операционные Системы.
- •Лекция 1.
- •Лекция 2.
- •Типы файлов:
- •Лекция 3 Файловая система fat:
- •Логика работы ос по поиску файлов в файловой системе fat:
- •Лекция 4
- •Файловая система ntfs:
- •Структура файловой системы ntfs:
- •Логика поиска файлов в файловой системе ntfs:
- •Лекция 5
- •Файловые системы ufs and s5
- •Логика поиска файлов в фс s5
- •Файловая система ext2:
- •Логика поиска в файловой системе ext2
- •Архитектура ос Монолитная архитектура
- •Микро ядерная архитектура
- •Лекция 6
- •Мульти программирование
- •Процессы и потоки
- •Планирование и диспетчеризация потоков
- •Мульти программирование прерываний
- •Лекция 7
- •Синхронизации процессов и потоков
- •Проблемы при синхронизации:
- •Лекция 9
Лекция 7
понедельник, 16 апреля 2012 г.
Диспетчер прерываний – существует в нем понятие маскирование – это временный отказ от обработки прерываний любого класса независимо от уровня прерывания, последовательность действий при обработки прерываний:
При возникновении сигнала при обработке сигнала управление передаётся диспетчеру.
Диспетчер определяет тип и класс прерываний.
Диспетчеру необходимо определить приоритет прерывания
В случаи если прерывание запрещено процессор не осуществляет данное прерывание и продолжает выполнение потока
Если прерывание не запрещено происходит прекращение действия потока, сохранение всех сведений о нем, выбор обработчика прерываний, а так же определение его адреса для передачи управления данному обработчику. При этом временно запрещаются все прерывания данного типа.
Восстановление контекста данного потока или переход к другому обработчику прерываний.
Для эффективной работы прерываний в ядре ОС всегда должен находится диспетчер прерываний, его основной целью является:
Обеспечивает работы диспетчера прерываний.
Образование очередей обработчика прерываний по аналогии с процессом.
Синхронизации процессов и потоков
Потребность в синхронизации потоков возникает только в мульти программированной ОС и связана с совместным использованием аппаратных и информационных ресурсов ВычСистем. Синхронизация необходима для исключения гонок и тупиков при обмене данными между потоками, разделение данными, а так же при доступе к процессору и устройствам ввода вывода.
Во многих ОС эти средства называются Inter Process Communication (IPC). Вып потока в мульти прог среде всегда имеет асинхронный характер.
Очень сложно с полной определённостью сказать на каком этапе выполнения будет находиться процесс в определённый момент времени. Так как исходные данные в разные моменты запуска задачи могут быть разными. То и время вып отдельных этапов и задачи в целом является весьма неопределённой величиной. Ещё более не определённым является время выполнения программы в мульти программной системе.
Моменты прерывания потоков, время нахождения их в очереди(к разным ресурсам), порядок выбора потоков для выполнения – все эти события являются результатом стечения многих обстоятельств и могут быть интерпретированы как случайные.
В лучшем случае можно определить вероятностные хар-ки выч процесса – вероятность завершения процесса на заданный период времени.
Таким образом потоки в общем случае протекают независимо или асинхронно друг от друга это утверждение справедливо как по утверждению к потоком одного процесса(вып одну общ задачу) так и по отнош потоков разных процессов каждый из которых выполняет собственную задачу.
Любое взаимодействие процессов или потоков связанно с их синхронизацией, которая заключается в согласовании их скоростей путём приостановки потока до наступления некоторого события и последующей его активизации после совершения данного события.
Синхронизация лежит в основе любого взаимодействия потоков, не важно, связанно ли это с взаимодействием ресурсов или обменом данными.
Пренебрежение вопросов синхронизации в многопоточной системе может привезти к неправильному решению задачи или даже краху системы.
Пример: задача состоит в ведении базы данных клиентов некоторого предприятия. Каждому клиенту отводиться своя строка в базе данных в которой имеются поля заказ и оплата, программа ведущая базу данных оформлена как единый процесс имеющий несколько потоков в том числе поток: а) заносит инф о заказах поступивших от клиентов и поток б) фиксирует в базе данных сведения об оплате выставленных счетов. Оба потока совместно работают над файлом базы данных используя при этом однотипный алгоритм:
Этапы алгоритма
Считать из файла базу данных в буфер, запись о клиенте с заданным идентификатором.
Для потока а) внести новое значение в поле заказ, а для потока б) внести новое значение в поле оплаты.
Вернуть модифицированную запись в файл оплаты.
Обозначим соответствующие шаги для потока а1, а2, … б1, б2 … предположим что в некоторый момент поток а) обновляет поле заказ записи о клиенте «Н» для этого он считывает запись в свой буфер шаг а1, модифицирует значение в поле заказ шаг а2 но внести изменение в базу данных шаг а3 не успевает. Так как его выполнение прерывается в следствии завершения кванта времени.
Так же предположим что потоку б) требовалось внести данные о клиенте «Н» когда приходит очередь потока б) он успевает считать запись в свой буфер шаг б1, выполнить обновление поля оплата шаг б2, и прерывается при этом заметим что в буфере у потока б) находиться запись о клиенте «Н» в котором поле заказ имеет все ещё имеет низменное значение. Когда в очередной раз управление будет передано значение в поток а) он запишет в запись о клиенте «Н» модифицированное значение. После заверш а) и активизации б) в базу данных поверх обновленной записи о клиенте «Н» будет записана обновленное значение в поле оплата но старое значение в поле заказ шаг б3 выполниться но снова измениться поле заказ.
Сложность проблемы синхронизации в не регулярности ситуации. Так в данной ситуации могла возникнуть ситуация с потерей информации не о заказе, а о потере оплаты, или же удачное занесение в базу данных. В данном случае проблема синхронизации, состоит в отладке взаимодействующих потоков по соотношению их скоростей данные ситуации называются гонками.