Задачи принт-сервера

Таким образом можно регулировать доступ к общему ресурсу некоторого количества задач.

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

Чаще всего проблемы возникают с потоками в рамках одного программного модуляю

В Windows предусмотрено управление мьютексами специальной функцией:

CriticalSection

Свойства синхронизации выбираются непосредственно в зависимости от используемой ОС.

Наиболее плохим последствием неверной синхронизации является "смертельный захват" (зависание ОС)

Например, задача 1 захватывает ресурс клавиатуры и ждет, пока освободится дисплей. Дисплей занят задачей 2, но для ее завершения нужно обратиться к клавиатуре.

Чтобы избавиться от таких ситуаций, если нет сервера ресурсов, используют такой искусственный прием: в зависимости от типа разрабатываемой системы, разработчик устанавливает некоторое критическое время ожидания. Если за это время не получен нужный ресурс, задачи должны освободить все, что они успели занять.

Использование мьютексов чревато появлением инверсии приоритетов.

Пусть есть 3 задачи: 1-ая имеет высший приоритет, третья -- низший. Высокоприоритетная и среднеприоритетная задачи запланированы по прерыванию внешнего события. Значит, задача 3 спокойно захватывает семафор и начинает выполнение. Задача 3 выполняется; задача 1 получает прерывание и, как более высокоприоритетная, заблокирует задачу 3. Но задача 3 не освободила семафор -- следовательно, задача 1 тоже заблокируется -- следовательно, две задачи заблокированы -- следовательно, управление получит оставшаяся задача (2). Получаем, что высокоприоритетная задача не выполняется, т.к. нужный ей ресурс занимает низкоприоритетная.

Еще одной проблемой является синхронизация с внешними событиями. Чаще всего для этого используются прерывания.

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

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

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

Очень много ограничений на обработки прерываний накладывает аппаратная платформа.

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

Еще одной задачей синхронизации является синхронизация каких-либо событий относительно астрономического времени или внутреннего времени системы. Сегодня любые вычислительные системы имеют несколько программируемых таймеров, и внутреннюю синхронизацию выполняют, привязываясь к этим показаниям. Эталонный квант времени в СРВ называется тиком (tick). И все задержки и события делаются кратными тику.

Многофункциональные таймеры обязательно имеют батарейную поддержку.

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

Также используются навигационные приемники ГЛОНАСС и GPS, имеющие высокую точность.

Особенности тестирования:

Непосредственно на оборудовании тестирование не проводится, т.к. это может привести к материальным затратам. Тестирование проводится в различных эмуляторах.

Тесты для таких систем должны быть очень тщательно проработаны и обязательно "прогонять" худшие случаи.

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

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

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

Также кэш может сильно влиять на показатели быстродействия (я бы добавил, что и cache, и cash -- тупое прим. от себя %)) Наиболее сложно тестировать системы.

материал выше -- для первой контрольной