ЖУРНАЛ «СТА» №1/2007

дой значимой подсистемы программно- го продукта. Разработчик таким обра- зом получает гарантию того, что полная загрузка системных ресурсов одной подсистемой не повлияет на функцио- нирование других подсистем. Такой подход предотвращает поглощение всех ресурсов процессора одним потоком, даже если поток запущен с самым высо- ким уровнем приоритета. В пределах раздела обработка потоков планируется с учётом традиционных правил прерывания планировщика, ос- нованного на приоритетах. К разделу применяются стандартные правила планировщика: FIFO, round robin и спорадическое правило. В результате каждый раздел становится минисредой исполнения. Работа планировщиков разделов раз- личается. Некоторые чётко распределя- ют бюджетное время процессорной об- работки, так что каждый раздел получает установленный бюджет процессорных ресурсов, даже когда в этом нет особой необходимости. Другие могут динамиче- ски распределять неиспользуемые ре- сурсы процессора другим разделам, мак- симизируя таким образом использова- ние процессора и позволяя системе справляться с пиками запросов. У ПРОЩЕНИЕ ПРОЦЕССА РАЗРАБОТКИ И ИНТЕГРАЦИОННОГО ТЕСТИРОВАНИЯ Распределение процессорного време- ни облегчает процесс параллельной раз- работки, позволяя разработчику назна- чить гарантированный бюджет процес- сорных ресурсов для каждой субсисте- мы. Такой подход устраняет необходи- мость применять глобальные схемы приоритетов и позволяет разработчи- кам определять схемы приоритетов на уровне субсистем в зависимости от по- требностей. В результате становится возможным ведение процесса парал- лельной разработки. При тестировании функционирова- ния субсистемы внутри раздела разра- ботчики могут создавать условия пол- ной загрузки процессора вне этого раз- дела, симулируя таким образом работу системы при полной загрузке процессо- ра. Это позволяет разработчикам произ- водить отладку своего программного кода в неблагоприятных условиях пол- ного использования системных ресур- сов. В результате решается большое ко- личество проблем, связанных с произ- водительностью и использованием про- цессорного времени до стадии интегра- ции системы. Чтобы оценить все преимущества разделения процессорного времени, рассмотрим относительно простую сис- тему, спроектированную без использо- вания алгоритма распределения про- цессорного времени. Система, изобра- жённая на рис. 2, содержит следующие процессы: ● процесс со средним приоритетом, ответственный за функционирова- ние локального человекомашинно- го интерфейса; ● процесс со средним приоритетом, производящий периодическое сен- сорное сканирование; ● процесс с высоким приоритетом, от- ветственный за управление двигате- лем; ● процесс с низким приоритетом, от- ветственный за функционирование удалённой системы мониторинга, которая посылает обновлённые дан- ные центральной системе монито- ринга, основанной на Интернеттех- нологии. На этапе интеграции, когда вся сис- тема собрана, система webмонито- ринга работает прекрасно до тех пор, пока не используется локальный чело- векомашинный интерфейс. При его использовании система мониторинга «замирает» и перестаёт отображать об- новленные данные. Проблемы возни- кают, когда к процессу управления двигателем, работающему с высоким приоритетом, добавляется процесс, отвечающий за команды локального человекомашинного интерфейса, аб- солютно вытесняя процесс монито- ринга с более низким приоритетом. Анализ приоритетов объясняет, поче- му это происходит. При полной за- грузке процессора процессы с малым приоритетом не получают процессор- ного времени обработки. Чтобы решить данную проблему, раз- работчик назначает процессу, отвечаю- щему за команды локального челове- комашинного интерфейса, более низ- кий приоритет, чем процессу монито- ринга. Однако это делает невозможным адекватную работу человекомашинно- го интерфейса. Назначение среднего приоритета трём процессам: процессу, производящему сенсорное сканирова- ние, процессу, ответственному за функ- ционирование удалённой системы мо- ниторинга, и процессу, отвечающему за команды локального человекомашин- ного интерфейса, – также ничего не да- ёт – производительность трёх процес- сов снижается. Так как переназначение приоритетов не даёт должного результа- та, разработчик должен сделать следую- щий шаг и попытаться изменить пове- дение потока, а это дорогостоящее ре- шение на стадии интеграции. Разделение процессорного времени позволяет избежать всех этих проблем. Например, разработчик может устано- вить бюджет процессорного времени для каждого из четырех разделов (рис. 3): 10% для процесса, отвечающе- го за команды локального человекома- шинного интерфейса, 10% для процес- са, ответственного за функционирова- ние удалённой системы мониторинга, 30% для процесса, производящего сен- сорное сканирование, и 50% для про- цесса, ответственного за управление двигателем. При таком подходе каждый раздел бу- дет функционировать в соответствии с выделенным бюджетом процессорного времени. При сборке системы на стадии интеграции все процессы гарантиро- ванно получат выделенную бюджетом долю процессорного времени. В резуль- тате ни один процесс не будет обделён процессорными ресурсами и, более то- го, у разработчика появится возмож- ность настройки производительности системы простой регулировкой бюдже- тов процессорного времени для каждо- го из разделов. П Р О Г РАММНО Е ОБ Е С П Е Ч Е НИ Е / СИС Т ЕМЫ Р Е АЛ Ь НО ГО В Р ЕМЕ НИ 73 СТА 1/2007 www.cta.ru 30% 50% 10% 10% Сенсорное сканирование Система управления двигателем Система мониторинга ЧМИ Рис. 3. Распределение бюджетов процессорного времени между процессами