Itogi_Shpory

87. Проектирование разъемов для межзадачных Коммуникаций

Классы-разъемы инкапсулируют детали межзадачных коммуникаций, такие как, сильно и слабо связанный обмен сообщениями. Многозадачное ядро предоставляет сервисы для межзадачных коммуникаций и синхронизации. Похожие механизмы существую в таких языках параллельного программирования, как Ada и Java. Но эти языки не поддерживает слабо связанный обмен сообщениями. Чтобы осуществить такую возможность, следует спроектировать скрывающий информацию класс MessageQueue, который инкапсулирует очередь сообщений и предоставляет операции для доступа к ней. Классы такого вида и есть разъемы. Есть три класса-разъема для реализации слабо связанного обмена сообщениями, сильно связанного обмена без ответа и сильно связанного обмена с ответом. Разъем - это монитор, который одновременно обеспечивает синхронизацию и скрывает информацию о том, каким образом это происходит. В разъемах используется синхронизация по условию. Такие мониторы применяются в однопроцессорной и в многопроцессорной системе с разделяемой памятью.

88. Проектирование разъема, реализующего очередь сообщений

Разъем, который осуществляет очередь сообщений, применяется для инкапсуляции механизма слабо связанного обмена сообщениями. Это монитор, который инкапсулирует очередь, обычно имеющую вид связанного списка. Разъем предоставляет синхронизированные операции для отправки сообщения send, вызывающиеся задачей-производителем и для получения сообщения receive, вызывающиеся задачей-получателем.

В случае, если очередь заполнена (messageCount = maxCount) Производитель останавливается, а когда освобождается место для нового сообщения, продолжает работу. Поставив сообщение в очередь, производитель продолжает работать и может посылать новые сообщения. Если в очереди нет сообщений (messageCount = 0), Потребитель останавливается, и активизируется при поступлении сообщения в очередь. Если сообщения в очереди есть, Потребитель не останавливается. Может существовать несколько производителей и 1 потребитель.

89. Проектирование разъема, реализующего буфер сообщений

Разъем, который осуществляет буфер сообщений, применяется для инкапсуляции механизма сильно связанного обмена сообщениями без ответа. Это монитор, который инкапсулирует буфер на 1 сообщение. Разъем предоставляет синхронизированные операции для отправки и получения сообщений. Операцию send вызывает Производитель, receive - потребитель. Если буфер заполнен, Производитель останавливается. При помещении сообщения в буфер, производитель ожидает того момента, когда потребитель примет сообщение. Когда в буфере нет сообщения, Потребитель останавливается. При этом может быть несколько производителей и 1 потребитель.

90. Проектирование разъема, реализующего буфер сообщений с ответом

Разъем, которые реализуют буфер сообщений с ответом, применяются для инкапсуляции механизма сильно связанного обмена сообщениями с ответом. Это монитор, который инкапсулирует буфер на 1 сообщение и буфер на 1 ответ. Разъем предоставляет синхронизированные операции для отправки, получения сообщений и для отправки ответа. Операцию send Производитель вызывает для пересылки сообщения, receive - Потребитель для приема сообщения и reply для отправки ответа. Поместив сообщение в буфер, производитель ждет ответа от потребителя. Когда в буфере нет сообщения Потребитель останавливается. При этом может быть несколько производителей и 1 потребитель.

91. Проектирование кооперативных задач с использованием разъемов

В качестве примера проектирования группы кооперативных задач, общающихся между собой с помощью объектов-разъемов приведем пример из подсистемы Банкомат. Существует 2 разъема - очереди сообщений и 1 разъем – буфер сообщений. Объект Очередь Сообщений Управления Банкоматом инкапсулирует очередь входных сообщений задачи Контроллер Банкомата, для которой существует несколько производителей. Объект Очередь Сообщений Приглашений инкапсулирует очередь сообщений, посылаемых задачей Контроллер Банкомата задаче Интерфейс Клиента. В обоих случаях производитель вызывает операцию send объекта-разъема, а потребитель – операцию receive. Разъем буфер Сообщений Устройства Считывания инкапсулирует синхронный обмен без ответа между задачами Контроллер Банкомата и Интерфейс Устройства Считывания Карточек.

Также есть объект заместитель Банковского Сервера, который скрывает детали коммуникации с удаленным Банковским Сервером, применяя при этом синхронный обмен сообщениями без ответа. Так, в языке Java такой заместитель применил бы механизм вызова удаленных методов (RMI).

92. Логика упорядочения событий

Раздел «Логика упорядочения событий» в спецификации поведения задач заполняется на этапе детального проектирования ПО. Логика упорядочения событий описывается неформально на псевдокоде или на естественном языке, а также может дополняться диаграммой. Так, для управляющей задачи можно построить диаграмма перехода состояний. Если задача составная с несколькими вложенными объектами входные сообщения принимает вложенный объекткоординатор. После чего он вызывает операции других объектов. То есть объекткоординатор осуществляет логику упорядочения событий.

93. Анализ производительности проекта параллельной системы

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

94. Теория планирования в реальном времени. Планирование периодических задач

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

В начале алгоритмы планирования в реальном времени создавались для независимых периодических задач. Периодическая задача характеризуется периодом Т - частотой запуска и временем выполнения С - временем ЦП, необходимым для завершения 1 запуска. Коэффициент использования ЦП вычисляется по формуле U = С/Т. Если задача удовлетворяет всем временным ограничениям и ее выполнение заканчивается до конца периода, то она - планируемая. Если все задачи, входящие в группу задач планируемые, то и сама группа планируемая.

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

95. Теорема о верхней границе коэффициента использования ЦП

Теорема о верхней границе коэффициента использования ЦП:

Множество из n независимых периодических задач, планируемых согласно алгоритму монотонных частот, всегда удовлетворяет временным ограничениям, если

С1 ... Cn n(21 / n 1) U (n)

T1 Tn

где Сi– время выполнения, Тi - период задачи.

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

Обобщенная теорема о верхней границе коэффициента использования:

Ui – верхняя граница коэффициента использования ЦП за период Тi для задачи ti. 1-й член в полученной формуле – суммарное использование за счет вытеснения высокоприоритетными задачами с периодом меньшим, чем у ti. 2-й член соответствует использованию процессора задачей ti 3-й член учитывает время блокировки задачи ti в худшем случае, а 4-й – суммарное время вытеснения этой задачи более приоритетными, но с периодами меньшими, чем у ti.

Достоинство алгоритма монотонных частот – это то, что он сохраняет устойчивость в условиях краткосрочной перегрузки.

98. Планирование периодических и апериодических задач. Планирование с синхронизацией задач

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

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

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

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

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

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

Еще одна возможная проблема – это тупиковая ситуация (deadlock), которая возникает, когда двум задачам нужно захватить по два ресурса. Если каждая задача захватит по одному ресурсу, то ни одна не сможет завершиться, поскольку будет ждать, пока другая освободит ресурс. Протокол предельного приоритета справляется и с такой трудностью.

99. Развитие теории планирования в реальном времени

В теории планирования в реальном времени рассматриваются вопросы приори-

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

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

100. Планирование в реальном времени и проектирование. Пример применения обобщенной теории планирования в реальном времени

Теорию планирования в реальном времени можно применить к множеству параллельных задач либо на этапе проектирования, либо уже после реализации всех задач. Поскольку во время проектирования для времени ЦП существуют только приблизительные оценки, нужно быть осторожнее и при разработке задач реального времени с жесткими временными ограничениями полагаться на пессимистическую теорему о верхней границе коэффициента использования. Эта теорема дает верхнюю границу 0,69 в худшем случае, хотя теория планирования в реальном времени часто указывает более высокие значения. Если верхняя граница в худшем случае не может быть достигнута, придется изучить альтернативные решения.

В качестве примера рассмотрим следующий случай. Есть четыре задачи: две периодические и две апериодические. Ниже приведены детальные характеристики задач, причем время указано в миллисекундах, а коэффициент использования Ui=Ci/Ti.

Периодическая задача t1: С1 = 20; Т1 = 100; U1 = 0,2. Апериодическая задача t2: С2 = 15; Т2 = 150; U2 = 0,1. Управляемая прерываниями задача ta: Сa = 4; Тa = 200; Ua = 0,02. Периодическая задача t3: C3 = 30; T3 = 300; U3 = 0,1.

Кроме того, известно, что задачи t1, t2 и t3 обращаются к одному и тому же хранилищу данных, защищенному семафором S.

Задачам назначены приоритеты в строгом соответствии с алгоритмом монотонных частот, то есть t1 имеет наивысший приоритет, а за ней следуют t2, ta и t3 Но, поскольку для ta время реакции жестко ограничено, ей присвоен наивысший приоритет, а уже потом идут t1, t2 и t3.

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

– время вытеснения более приоритетными задачами с периодами меньшими, чем Т1. Таких задач

нет;

–время выполнения С1 задачи t1 равно 20. Коэффициент использования U1 = 0,2;

–вытеснение более приоритетными задачами с большими периодами. В эту категорию попадает задача ta. Коэффициент использования за счет вытеснения на периоде Т1 равен Сa/Т1 = 4/100 = 0,04;

–время блокировки задачами с более низким приоритетом. Потенциально заблокировать t1 могут задачи t2 и t3. Коэффициент использования за счет блокировки на периоде Т1 составляет B3/Т1 = 30/100 = 0,3.

Коэффициент использования в худшем случае равен сумме всех полученных коэффициентов, то

есть 0,04 + 0,2 + 0,3 = 0,54, что меньше верхней границы 0,69. Следовательно, t1 удовлетворяет временным ограничениям.

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

101. Анализ производительности с помощью анализа последовательности событий

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

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

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

102.Анализ производительности с помощью теории планирования в реальном времени и анализа последовательности событий

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

Для начала назначить всем задачам в цепочке одинаковые приоритеты. С точки зрения теории планирования в реальном времени вместо них можно рассмотреть одну эквивалентную задачу. В качестве периода эквивалентной задачи устанавливается время

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

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

103.Пример анализа производительности с помощью анализа последовательности событий

В качестве примера рассмотрим подсистему Круиз-Контроль из системы круизконтроля и мониторинга. Проанализируем случай, когда водитель переводит ручку круиз-контроля в положение «Разгон», инициируя тем самым автоматическое ускорение машины. В требованиях к системе записано, что система должна отреагировать на это действие в течение 250 мс. Предположим, что у подсистема Круиз-Контроль находится в состоянии Начальное. Имеем последовательность событий С1-С9.

Скажем, для обработки внешнего события «Разгон» требуется четыре задачи (Интерфейс Ручки Круиз-Контроля, Круиз-Контроль, Корректировка Скорости и Интерфейс Дросселя).

Т.к. задействовано 4 задачи, то имеется как минимум четыре контекстных

переключения, на которые тратится время 4Сx, где Сx – время, необходимое для одного переключения.

Полное время, которое ЦП расходует на эти четыре задачи (Сe), равно сумме времен выполнения каждой задачи и времени, необходимого для межзадачных коммуникаций, плюс затраты на контекстное переключение:

Сe = С1 + C2 + С3 + С4 + С5 + С6 + С7 + С8 + 4Сx.

Предположим, что затраты на межзадачные коммуникации Сm постоянны. Тогда С3, С5 и С7 равны Сm, так что полное время выполнения составит:

Сe = С1 + C2 + С4 + С6 + С8 + 3Сm + 4Сx.

Чтобы определить время реакции системы, необходимо также принять во внимание другие задачи (Сa), которые способны выполняться, пока система обрабатывает внешнее событие.

Полное время ЦП не должно превышать предельное время реакции, указанное в требованиях к системе (в нашем случае 250 мс). Это полное время равно:

Сt = Сe + Сa.

Прежде чем решать приведенные уравнения, нужно оценить каждый из временных параметров.