Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ОСРВ ответы.doc
Скачиваний:
0
Добавлен:
01.03.2025
Размер:
692.74 Кб
Скачать

Національний аерокосмічний університет ім. М.Є.Жуковського "хаі"

Спеціальність 7.080403. Курс 5.

Учбова дисципліна "Проектування ПЗ для спеціалізованих автоматизованих систем"

Екзаменаційний квиток № 3

 

  1. Перемикач задач. Модель, призначення. Контекст процесу, черга задач.

Рассмотрим, что же происходит при переключении процессов (пото-

ков). Для этого понадобится несколько новых понятий.

Контекст задачи - это набор данных, задающих состояние процес-

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

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

ной памятью может включать регистры, отвечающие за трансляцию

виртуального адреса в физический (обычно доступны на запись только

операционной системе).

Переключение задач - это переход процессора от исполнения од-

ной задачи к другой. Может быть инициировано:

− планировщиком задач (например, освободился ресурс и в

очередь готовых задач попала ожидавшая его приоритетная

задача),

− прерыванием (аппаратным прерыванием) (например, запрос

на обслуживание от внешнего устройства),

− исключением (программным прерыванием) (например, сис-

темный вызов).

Поскольку контекст полностью определяет, какая задача будет вы-

полняться, то зачастую термины "переключение задач" и "переключе-

ние контекста" употребляют как синонимы.

Диспетчер (dispatcher) - это подпрограмма (часть ядра), отвечающий

за переключение контекста.

При переключении задач диспетчеру необходимо:

1. корректно остановить работающую задачу; для этого

а) выполнить инструкции текущей задачи, уже загруженные в про-

цессор, но еще не выполненные (современные процессоры имеют

внутри себя конвейеры инструкций, куда могут загружаться более 10 ин-

струкций, некоторые из которых могут быть весьма сложными, напри-

мер, записать в память 32 регистра), обычно это делается аппаратно;

б) сохранить в оперативной памяти регистры текущей задачи;

2. Найти, подготовить и загрузить затребованную задачу (обработ-

чик прерываний - в этом случае требуется еще установить источник

прерывания);

3. Запустить новую задачу, для этого

а) восстановить из оперативной памяти регистры новой задачи (со-

храненные ранее, если она до этого уже работала);

б) загрузить в процессор инструкции новой u1079 задачи (современные

процессоры начинают выполнять инструкции только после загрузки

конвейера), эта фаза делается аппаратно.

Каждая из этих стадий вносит свой вклад в задержку при переклю-

чении контекста. Поскольку любое приложение реального времени

должно обеспечить выдачу результата в заданное время, то эта за-

держка должна быть мала, детерминирована и известна. Это число

является одной из важнейших характеристик ОСРВ.

Детерминированность особенно важна при обработке прерываний,

поскольку их может быть несколько в очереди прерываний, и обработ-

чик должен обслужить их все. Прерывания являются основным источ-

ником сообщения внешним устройством о готовности данных или необ-

ходимости передачи данных. По самому назначению систем реального

времени, прерывания являются одним из основных объектов в ОСРВ

  1. Синхронізація процесів: семафори і м’ютекси

Синхронизация процессов — приведение двух или нескольких процессов к такому их протеканию, когда определённые стадии разных процессов совершаются в определённом порядке, либо одновременно.

Синхронизация необходима в любых случаях, когда параллельно протекающим процессам необходимо взаимодействовать. Для её организации используются средства межпроцессного взаимодействия. Среди наиболее часто используемых средств — сигналы и сообщения, семафоры и мьютексы, каналы (англ. pipe), совместно используемая память.

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

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

Тем не менее, есть ряд частных способов, применимых в тех или иных случаях:

  • Наиболее простой способ: предполагают, что изменения вносились лишь в одну из копий — «рабочую» — и другая копия просто перезаписывается её содержимым. Этот способ реализуют большинство приложений синхронизации; в силу необратимости делаемых изменений пользователю даётся выбор, какую копию считать «главной».

  • Если данные представляют собой набор независимых записей (то есть любое сочетание записей является корректным — это, напр., телефонная книга), то можно просто объединить множества записей. Это ликвидирует риск потери информации, но чтобы удалить запись из набора, этот способ приходится сочетать с первым.

    • Если наборы синхронизируются неоднократно, можно автоматически вводить в них дополнительную служебную информацию: дата и время последнего изменения записи, пометки об удалённых записях (стираются после следующей синхронизации или через достаточно большое время) и пр. . Этот подход используется, например, в Outlook.

  • Обрабатывать конфликты правок: автоматически (если возможно), иначе — вручную. Этот, наиболее общий способ применяется только если указанные выше упрощённые недопустимы — например, в системах контроля версий. Так, CVS при обнаружении двух независимых изменений объявляет о «конфликте» и либо (в простых случаях) разрешает его автоматически, либо предоставляет пользователю разрешить его вручную. В этих случаях конфликтов стараются просто избегать — например, распределением областей компетенции.

Одним из механизмов синхронизации данных является репликация, которая в частности находит применение для синхронизации содержимого баз данных.

Мью́текс (англ. mutex, от mutual exclusion — «взаимное исключение») — одноместный семафор, служащий в программировании для синхронизации одновременно выполняющихся потоков.

Мьютексы — это один из вариантов семафорных механизмов для организации взаимного исключения. Они реализованы во многих ОС, их основное назначение — организация взаимного исключения для потоков из одного и того же или из разных процессов.

Мьютексы — это простейшие двоичные семафоры, которые могут находиться в одном из двух состояний — отмеченном или неотмеченном (открыт и закрыт соответственно). Когда какой-либо поток, принадлежащий любому процессу, становится владельцем объекта mutex, последний переводится в неотмеченное состояние. Если задача освобождает мьютекс, его состояние становится отмеченным.

Задача мьютекса — защита объекта от доступа к нему других потоков, отличных от того, который завладел мьютексом. В каждый конкретный момент только один поток может владеть объектом, защищённым мьютексом. Если другому потоку будет нужен доступ к переменной, защищённой мьютексом, то этот поток засыпает до тех пор, пока мьютекс не будет освобождён.

Цель использования мьютексов — защита данных от повреждения; однако им порождаются другие проблемы — такие, как взаимная блокировка (клинч) и состояние гонки.

Мьютекс отличается от спинлока наличием очереди ожидающих потоков.

 

Затверджено на засіданні кафедри 603.

Протокол № __1_ від "_28_" ___08___ 2009 р.

 

Зав. кафедрою ___________ /Туркін І.Б/

Екзаменатор __________ /Туркін І.Б./