В
с
т
р
а
и
В
а
е
м
ы
е
с
и
с
т
е
м
ы
59
электронные компоненты No5 2008
В статье рассмотрены основные особенности операционных систем
реального времени для цифровой обработки сигналов. Перечислены их
характеристики и описаны функциональные возможности. Показана
необходимость применения подобных систем, которые обеспечивают
разработчику необходимый уровень абстракции от сложной аппарат-
ной части и значительно сокращают время разработки. Статья пред-
ставляет собой сокращенный перевод [1].
ОПераЦиОНые системы реаЛЬНОГО
ВремеНи ДЛЯ ЦиФрОВОЙ
ОБраБОтКи сиГНаЛа. Часть 1
РобеРт ошана (RobeRt oshana), DSP DesignLine
ВВедение
Современные системы обработки
сигнала управляются операционными
системами реального времени (ОСРВ).
Последние обеспечивают многозадач-
ную работу, обрабатывают внешние
прерывания и эффективно управляют
ресурсами системы, например: пря-
мым доступом к памяти, встроенной
памятью, вводом/выводом, периферией.
ОС и, в частности, ОСРВ, загружаются
программой-загрузчиком при включе-
нии процессора и управляют другими
программами, которые называются при-
ложениями или задачами. ОС — элемент
системного программирования. ОС обе-
спечивает инфраструктуру для приклад-
ного ПО и позволяет абстрагироваться
от аппаратного обеспечения (см. рис.1).
Приложения взаимодействуют с
операционной системой, вызывая ее
службы через заданный программный
интерфейс приложений — application
program interface (API). ОС общего назна-
чения предоставляет приложениям сле-
дующие сервисы:
–
в многозадачной ОС определяют
порядок выполнения и время, выделяе-
мое каждому приложению;
–
ОС управляет распределением
встроенной памяти между несколькими
приложениями;
–
ОС обеспечивает обмен данными
с внешними устройствами;
–
ОС рассылает приложениям и
пользователям оповещения о статусе
операций и любых ошибках, которые
могут произойти;
–
ОС может управлять исполнением
так называемых пакетных задач (batch
jobs), например, печати, освобождая
вызвавшее их приложение;
–
при параллельном вычислении ОС
с разделением задач загружает несколь-
ко процессоров одновременно.
По некоторым параметрам практи-
чески любая ОС общего назначения
(например, Windows NT) обладает при-
знаками систем реального времени. Но
мы определим ОСРВ как особый класс
операционных систем, которые гаран-
тируют выполнение определенных
действий за определенный интервал
времени. ОСРВ должна обладать рядом
свойств. Самое важное — ОСРВ должна
быть многопоточной и поддерживать
вытесняющую многозадачность, а также
приоритеты задач. Чтобы ограничить
возможность нарушения приоритетов,
система должна поддерживать насле-
дование приоритетов. Отклонение от
выполнения задачи в реальном времени
(РВ) для управления ресурсами должно
быть крайне небольшим и точно извест-
ным заранее, чтобы было возможно
определить время выполнения задачи
в целом.
Планировщик управляет процессор-
ным временем и функциями РВ про-
цессора. Диспетчер памяти выделяет,
освобождает и защищает память кода
и данных. Драйверы управляют устрой-
ствами ввода/вывода, таймерами,
устройствами прямого доступа к памя-
ти и т.п. Помимо того, небольшая часть
рабочего времени ОСРВ использует для
явного управления ресурсами — чтобы
обеспечить приемлемый уровень пред-
сказания времени выполнения задания.
ВыбоР оСРВ
При выборе надо учитывать всю
процедуру разработки. Эффективность
исполнения операций только часть про-
блемы. Минимальная задержка обра-
ботки прерываний или переключения
контекста не так уж важна, если отсут-
ствие инструментов или поддержки
драйверов выведет проект из графика
на несколько месяцев. Вот несколько
пунктов, которые надо учитывать при
выборе.
1. Предназначена ли ОСРВ для
задач цифровой обработки сигнала?
Некоторые ОСРВ создаются для специ-
альных приложений, таких как цифровая
обработка сигналов или применение в
сотовом телефоне. Другие имеют более
общее назначение.
2. Насколько качественна докумен-
тация и поддержка?
3. Насколько хорошо поддерживает-
ся ОСРВ средствами разработки?
4. Насколько хороша поддержка
оборудования? Есть ли драйверы для
устройств, которые предполагается
использовать, и для тех, поддержка кото-
рых может потребоваться в будущем?
5. Подходит ли ОСРВ для решения
ваших задач? Для ОСРВ модульность
и расширяемость важнее, чем для ОС
общего назначения. Во встраиваемых
системах ядро должно быть компактным,
поскольку объемы ОЗУ и ПЗУ часто огра-
ничены. Поэтому многие ОСРВ построе-
ны на микроядре, которое обеспечивает
только основные функции: планирова-
ние задач, синхронизацию, обработку
прерываний, поддержку многозадачно-
сти.
6. Сертифицируема ли система?
Некоторые системы, для которых безо-
пасность является критичным условием,
требуют обязательной сертификации.
7. Особенности цифровой обработ-
ки сигналов. Выбор ОСРВ, ориентиро-
Рис. 1. Компоненты программного обеспечения
для встраиваемого цифрового сигнального про-
цессора

60
В
с
т
р
а
и
В
а
е
м
ы
е
с
и
с
т
е
м
ы
www. elcp.ru
ванной на цифровую обработку сигна-
лов, имеет ряд особенностей. Типичное
встраиваемое приложение ЦОС состо-
ит из двух основных компонентов —
системного и прикладного.
8. ОСРВ для ЦОС имеют очень
малое время реакции на прерывания.
Поскольку многие системы ЦОС взаи-
модействуют с внешним окружением,
они управляются событиями — или
прерываниями. По тем же причинам
ОСРВ для ЦОС гарантируют, что общее
время, в течение которого прерывания
отключены, минимально. Пока преры-
вания отключены (например, во время
переключения контекста), цифровой
сигнальный процессор не может реаги-
ровать на внешние события.
9. ОСРВ для ЦОС также реализуют
независимые от аппаратуры высокопро-
изводительные функции ввода/вывода.
Они обеспечивают базовые возможно-
сти ввода/вывода для взаимодействия
с другими потоками и устройствами.
Операции ввода/вывода должны быть
асинхронными, иметь малые задержки
и быть детерминированными — в том
смысле, что скорость передачи должна
быть одинаковой для любых объемов
данных.
10.ОСРВ для ЦОС также должна
иметь специализированные средства
управления памятью. Такая система
должна обеспечивать возможности для
эффективного распределения памяти и
ее конфигурирования.
11. Важна возможность распределе-
ния памяти и областей динамических
данных с минимальными потерями
объема. ОСРВ также должна взаимодей-
ствовать с различными типами памяти,
которые могут использоваться в систе-
ме ЦОС, включая статическую и дина-
мическую память, быструю память, раз-
мещенную на кристалле, и т.д.
ПоддеРжка уСтРойСтВ В
СиСтемах Реального ВРемени
для цифРоВой обРаботки
СигналоВ
Частью инфраструктуры поддержки
ОСРВ является ПО для доступа к раз-
личным периферийным устройствам
процессоров. Библиотека поддерж-
ки устройств — Chip Support Library
(CSL) — это динамическая библиотека,
используемая для настройки и управ-
ления встроенными периферийными
устройствами процессора, такими как
кэш, блок прямого доступа к памяти,
внешний интерфейс памяти, многока-
нальный буферизованный последова-
тельный порт, таймеры и т.д . Библиотека
обеспечивает как инициализацию
устройств, так и управление в про-
цессе работы и хорошо вписывается
в пакет ОСРВ для ЦОС, обеспечивая
необходимое абстрагирование от аппа-
ратуры. Производители процессоров
предоставляют такие библиотеки, как
правило, написанные на языке С, уже
оптимизированные по объему кода и
быстродействию.
Поскольку различные цифровые сиг-
нальные процессоры и семейства про-
цессоров используют различные пери-
ферийные устройства, для каждого из
процессоров нужна своя библиотека
поддержки. Абстрагирование от аппара-
туры (см. рис. 2), обеспечиваемое такими
библиотеками, мало влияет на произво-
дительность системы, и в то же время
обеспечивает серьезные преимущества
для разработчика:
–
сокращение времени разработ-
ки — от разработчика не требуется
досконально разбираться в большом
количестве регистров процессора, уро-
вень аппаратной абстракции библиоте-
ки поддержки обеспечивает прозрач-
ную работу;
–
стандартизация — правильно
разработанная библиотека поддержки
обеспечивает унифицированную мето-
дологию разработки определений про -
граммных интерфейсов (API), предлагае-
мых разработчикам систем;
–
инструментальная поддержка —
часто доступна поддержка со стороны
инструментов разработки для цифровых
сигнальных процессоров, упрощающая
генерацию заказных конфигураций и
инициализацию регистров системы;
–
управление ресурсами — базо-
вое управление ресурсами для пери-
ферийных блоков, имеющих несколько
каналов, портов, устройств и т.п. суще-
ственно упрощается.
концеПции оСРВ
ОСРВ подразумевают определен-
ную функциональность, необходимую
для эффективного выполнения своей
задачи — выполнения всех операций
в пределах определенных временных
интервалов. В этом разделе описаны
основные функции, реализуемые опера-
ционными системами.
Задачи. Задача — основная единица
программного обеспечения, с которой
имеет дело операционная система. В
разных ОС понятие задачи может незна-
чительно отличаться. Задача реализу-
ет вычислительную работу и является
основным элементом, которым опери-
рует планировщик. Ядро создает зада-
чу, выделяет для нее область в памяти
и переносит код, который требуется
выполнить в рамках задачи в ОЗУ. При
этом создается структура, называемая
блоком управления задачей. Задача —
это некий объем информации, ассоции-
рующийся с работой одного экземпляра
программы, которая может работать с
несколькими пользователями. С точки
зрения программы, задача — это инфор-
мация, необходимая для обслуживания
одного индивидуального пользовате-
ля или конкретный служебный запрос.
Типы задач реального времени:
–
периодические — выполняются
регулярно, в соответствии с заранее
рассчитанным графико м;
–
спорадические — переключаются
внешними событиями или условиями, с
предопределенной предельной часто -
той;
–
спонтанные — дополнительные
задачи, исполняемые в соответствии с
внешними событиями (или возможно-
стями) при наличии свободных ресур-
сов;
–
текущие — планируются на осно-
ве разделения времени, то есть, с фикси-
рованной долей процессорного време-
ни.
Многозадачность. Современные
процессоры МП выполняют только одну
инструкцию в каждый момент време-
ни, но из-за высокой производитель-
ности и быстрого переключения между
задачами создается иллюзия, что работа
нескольких программ и обслуживание
нескольких пользователей происходит
одновременно. В системах с приори-
тетным планированием каждой задаче
присваивается приоритет, основанный
на ее относительной важности, количе-
стве потребляемых ею ресурсов и дру-
гих факторов. Существуют три основных
типа многозадачности.
1. Вытесняющая — если высокопри-
оритетная задача готова к выполнению,
она может немедленно вытеснить зада-
чи с низким приоритетом и захватить
процессор без ожидания следующего
интервала планирования. В данном кон-
тексте «немедленно» означает сразу по
окончании текущего периода планиро-
вания. Эта задержка — один из самых
важных характеристик ядра ОСРВ и
главным образом определяет реакцию
системы на внешние воздействия.
2. Кооперативная — если задача
не готова к исполнению, она самостоя-
тельно освобождает управление про-
цессором, чтобы другие задачи могли
выполняться. Такой алгоритм не требует
Рис. 2 . Аппаратная абстракция упрощает работу с
периферийными устройствами

В
с
т
р
а
и
В
а
е
м
ы
е
с
и
с
т
е
м
ы
61
электронные компоненты No5 2008
особого планирования и в общем слу-
чае не пригоден для приложений реаль-
ного времени.
3. С разделением времени — имеет
низкую реактивность (ограниченную
длительностью интервала планирова-
ния). В ОСРВ алгоритм планирования
всегда использует разделение времени,
т. к . всегда есть не оперативные задачи,
например, взаимодействие с пользова-
телем, протоколирование и учет инфор-
мации и т.д. Эти задачи имеют низкий
приоритет, и их исполнение планирует-
ся в тех временных интервалах, в кото-
рых нет готовых к выполнению задач с
высоким приоритетом.
Быстрая реакция на прерывания.
Практически все DSP-процессоры и
процессоры общего назначения управ-
ляются прерываниями. Процессор, при-
ступив к исполнению последовательно-
сти инструкций одной программы, будет
продолжать до тех пор, пока задача не
будет выполнена или пока дальнейшее
выполнение не станет невозможным
(например, из-за ожидания системного
ресурса) или пока не будет получен сиг-
нал прерывания.
ОСРВ содержит код, называемый
обработчиком прерываний. Обработчик
прерываний устанавливает приоритеты
прерываний и сохраняет их в очере-
ди, если обработки ожидает несколько
прерываний. Затем планировщик ОСРВ
определяет, какой программе переда-
вать управление. Сигнал запроса преры-
вания — interrupt request (IRQ) — имеет
ассоциированное с ним числовое зна-
чение. Таким образом, процессор полу-
чает информацию, какое именно устрой-
ство послало сигнал запроса и может
выбрать определенную процедуру, обе-
спечивающую необходимую реакцию
на этот запрос. Каждому устройству и
его соединению с процессором должно
быть присвоено уникальное значение.
ПланиРоВание задач В оСРВ
Алгоритм планирования выполнения
задач — одна из самых важных особен-
ностей ОСРВ. Планировщик определяет,
какие задачи могут быть запущены в
данный момент. Планирование выпол-
няется на том же процессоре, что и
пользовательские задачи, и это снижает
эффективность использования ресур-
сов процессора. Существует множество
алгоритмов планирования и характе-
ристик планировщиков, но для систем
реального времени актуальны не все.
Планирование задач основано на систе-
ме приоритетов — задачи с высоким
приоритетом исполняются первыми.
Также планировщик задач должен быть
вытесняющим — если задача с высо-
ким приоритетом готова к исполнению,
она немедленно вытеснит работающую
задачу с более низким приоритетом. Эта
особенность для задач реального вре-
мени является необходимой. Наконец,
ОСРВ для ЦОС должна управляться
событиями и реагировать на внешние
события — такие, как прерывания — а
также и на внутренние события, если
понадобится.
Жаргон многозадачности. Тер-
минология часто смущает неопытных
разработчиков, поскольку существу-
ет множество различных технологий и
стратегий разделения процессорного
времени. Определяющие особенности
их заключаются в том, как задаче переда-
ется управление процессором, и как она
его теряет. Хотя с точки зрения разработ-
чика эти аспекты различны, в литературе
и разговорах их часто неявно связывают.
Выполнение задачи может прерываться
одним из следующих способов.
1. По «добровольному согласию» —
совместная (или корпоративная) много-
задачность. Чтобы процессор перешел
от выполнения одной задачи к другой,
останавливаемая задача должна сделать
соответствующий вызов ОС. Такие систе-
мы работают в многозадачном режиме
до тех пор, пока все задачи «доброволь-
но» делятся процессорным временем.
2. Только после выполнения зада-
чи — работа до завершения. С практиче-
ской точки зрения такой стиль требует,
чтобы все задачи имели относительно
малую длительность.

62
В
с
т
р
а
и
В
а
е
м
ы
е
с
и
с
т
е
м
ы
www. elcp.ru
3. По требованию планировщика —
вытесняющая многозадачность. В этом
варианте планировщик задач может
прервать выполнение задачи в любой
момент. В общем случае, вытесняющие
планировщики более пригодны для слу-
чаев с особыми требованиями к вре-
менным параметрам. Если планировщик
переключает задачи с фиксированными
интервалами, такой тип планирования
называется многозадачностью с кванто-
ванием времени.
Выбор задачи для выполнения может
производиться одним из следующих
способов.
1. Поочередно. Используется про-
стая очередь (FIFO) задач. Применяется
очень редко.
2. По очереди в фиксированном
цикле. Малоэффективный циклический
планировщик. Если цикл возможно
начинать заново только с определен-
ным фиксированным интервалом, то
такой планировщик называется цикли-
ческим с постоянной частотой (rate
cyclic scheduler).
3. По истечении определенного
периода времени. Очень формальный
тип разделения процессорного време-
ни, при котором интервалы, или кванты
времени, выделяемые задачам, фикси-
рованы. Если задачи обрабатываются в
порядке очереди (FIFO), то такой тип
называется карусельным (Round-robin).
Если задачи выбираются по другой
схеме, то это планирование с квантова-
нием времени.
4. По приоритету — для выполнения
выбирается задача с приоритетом выше,
чем у прочих.
Не все комбинации вышеперечислен-
ных типов планирования имеют смысл,
но в любом случае важно понимать, что
прерывание выполнения одной задачи
и выбор следующей — это разные меха-
низмы. Некоторые сочетания настолько
обычны (например, вытесняющая много-
задачность с приоритетами), что одна из
особенностей (учет приоритетов) часто
неправильно трактуется как элемент
другой (вытеснения). Фактически наи-
более разумным было бы использовать
невытесняющий (т.е. с выполнением до
завершения) планировщик с приори-
тетами задач. Но по техническим при-
чинам в ОСРВ чаще всего используются
вытесняющие планировщики с приори-
тетами.
Планировщик — основной компо-
нент ядра ОС. Он — как задача — выпол -
няется периодически вне зависимости
от изменений потоков. В однозадач-
ной системе планировщик не нужен,
поскольку в ней нет разделения рабоче-
го времени процессора между задачами.
Многозадачность же подразумевает пла-
нирование разделения процессорного
времени. В большинстве систем реаль-
ного времени планировщик вызывается
через равные интервалы времени, по
периодическому прерыванию тайме-
ра. Период, с которым инициируется
это прерывание, называется «частотой
пульса» системы. На каждом прерыва-
нии таймера ОСРВ обновляет состояние
системы, анализируя выполнение задач,
и делает выводы о предоставлении про-
цессора той или иной задаче.
Состояния задач. Уточнить ситуа-
цию можно, определив для каждой
задачи состояния, отличные от готовно -
сти к выполнению. Основные состояния
типичной ОСРВ перечислены ниже.
1. Спящее — поток переводится в
спящее состояние немедленно после
его создания и инициализации. Поток
запускается (и выходит из спящего
состояния) при возникновении событий
определенного типа (или типов). После
завершения выполнения поток повтор-
но переводится в спящее состояние.
2. Готовность — поток входит в
состояние готовности после того, как он
запущен или вытеснен. В этом состоя-
нии поток находится в очереди готов-
ности и может выполняться. ОСРВ может
иметь несколько очередей готовности.
При планировании с фиксированными
приоритетами для каждого приоритета
строится своя очередь.
3. Исполнение — поток находится в
состоянии исполнения.
4. Приостановленное состояние
(состояние блокирования) — запущен-
ный поток переводится в приостанов-
ленное или блокированное состояние,
когда его выполнение не может быть
продолжено по тем или иным причи-
нам. Ядро помещает приостановленные
потоки в отдельную очередь. Причин
для приостановки ЦПС может быть
несколько. Задача может быть забло-
кирована из-за невозможности досту-
па к ресурсам. Задача может ожидать
синхронизации с другими задачами,
завершения операции ввода/вывода
или установления состояния сигнала.
Задача может исчерпать свой бюджет,
или может возникнуть апериодическая
задача, требующая выполнения. ОСРВ
может поддерживать различные очере-
ди для задач, приостановленных или
заблокированных по различным причи-
нам (например, различные очереди для
задач, ожидающих разных ресурсов).
5. Останов— поток,который небудет
больше выполняться, переходит в оста-
новленное состояние. Остановленный
поток может быть уничтожен.
Различные ОСРВ имеют несколько
различающиеся наборы состояний. На
рисунке 3 показана модель состояний
ОСРВ для ЦОС DSP/BIOS компании Texas
Instruments. Большинство ОСРВ пред-
лагают выбор между карусельным или
последовательным планированием
потоков с равными приоритетами. При
карусельном планировании использу-
ется квантование времени и понятие
бюджета.
На каждое прерывание таймера пла-
нировщик уменьшает бюджет потока на
длительность интервала меж ду преры-
ваниями — период пульса системы. При
необходимости задачи будут выгружены
(поочередный алгоритм планирования
использует бесконечный интервал вре-
мени). С каждым прерыванием таймера
планировщик обновляет очередь готов-
ности и либо передает управление теку-
щей задаче, либо выгружает ее — если
она более не является задачей с наивыс-
шим приоритетом. Из-за предыдущих
действий некоторые потоки могут стать
готовыми (запущенные до завершения
отсчета таймера), и выполнение пото -
ка может быть прервано. Планировщик
соответственно изменит порядок оче-
реди и передаст управление первому
потоку в очереди с высшим приорите-
том.
ядРо оСРВ
Ядро — центральный элемент ОС,
обеспечивает набор базовых сервисов
для остальных частей ОС и реализует
Рис. 3 . Модель состояний задач (свытеснением)для системы реального времени DSP BIOS компании Texas
Instruments

В
с
т
р
а
и
В
а
е
м
ы
е
с
и
с
т
е
м
ы
63
электронные компоненты No5 2008
следующий набор функций.
1. Обработчик прерываний для
управления запросами, претендующими
на использование служб ядра.
2. Планировщик, определяющий,
какие задачи и в какой последователь-
ности будут использовать рабочее
время ядра.
3. Диспетчер ресурсов, управляю-
щий использованием системных ресур-
сов, таких как оперативная или долго-
временная память, и их распределением
меж ду различными задачами в системе.
Операционная система может содер-
жать и другие компоненты, такие как
диспетчер файлов, но они рассматри-
ваются отдельно от основных служб
ядра, необходимых для обеспечения
вычислительных возможностей. Есть
три причины, по которым ядро может
взять управление на себя, приостановив
выполнение текущей задачи:
–
ответ на системный вызов;
–
выполнение планирования и
работа служебных таймеров;
–
обработка внешних прерываний.
Высшим приоритетом обладают аппа-
ратные прерывания. Одно аппаратное
прерывание может прервать обработку
другого. Следующий уровень приорите-
та — программные прерывания. ОСРВ
может поддерживать различные про-
граммные прерывания. Программные
прерывания имеют более низкий при-
оритет, чем аппаратные, а также имеют
внутреннюю систему приоритетов.
Аппаратные прерывания могут вытес-
нять программные. По принципу работы
программные прерывания аналогичны
аппаратным и управляются внутренним
таймером. Программные прерывания
выполняются до завершения и не могут
быть заблокированы или приостановле-
ны. Низший уровень приоритета имеют
задачи. Задачи могут быть вытеснены
программными и аппаратными пре-
рываниями, а также задачами с более
высоким приоритетом. Задачи выполня-
ются до завершения или откладываются,
если произошло блокирование по при-
чине ожидания ресурсов, или добро-
вольно — как, например, в карусельном
алгоритме планирования задач.
СиСтемные ВызоВы
Приложение может получить доступ
к коду и данным ядра посредством про-
граммных интерфейсов приложений
(API). Программный интерфейс — это
специальный метод, предварительно
описанный в ОС или прикладном ПО,
посредством которого программист,
пишущий приложение, может делать
запросы к ОС и другим программам.
Системный вызов — это вызов одной
из функций API. Когда такой вызов
происходит, ядро сохраняет контекст
вызывающей задачи, переключается из
пользовательского режима в режим
ядра (для обеспечения защиты памяти),
выполняет функцию от лица вызвавшей
задачи и возвращается в пользователь-
ский режим.
динамичеСкое РаСПРе де ление
Памяти
Динамическое распределение памя-
ти позволяет размещать данные в памя-
ти по различным адресам. Настоящий
адрес в памяти обычно не имеет зна-
чения для приложения. Один из недо-
статков этого способа — возможность
фрагментации памяти. Такое случается,
когда несмотря на наличие достаточ-
ного свободного объема разместить
очередной блок невозможно — из -за
отсутствия достаточно большого непре-
рывного участка памяти.
оПРеделение ПотокоВ
Первый этап при разработке многоза-
дачной системы — это построение архи-
тектуры приложения в виде системы неза-
висимо от исполняемых потоков. Доступны
инструменты, помогающие разработчику
системы на этом этапе. В результате опре-
деления архитектуры получится набор
структурных схем, конечных автоматов,
диаграммы потоков данных. Пример набо-
ра независимых потоков при управлении
электродвигателем с помощью одного
процессора приведен на рисунке 4. В этой
схеме 4 независимых потока: основной
алгоритм управления — периодическая
задача, работающая с частотой 1 кГц;
поток обработки клавиатуры — аперио-
дическая задача, включаемая действиями
оператора; поток отображения на дис-
Рис. 4 . Приложение управления двигателем, разделенное нанезависимые потоки
плее — периодическая задача, выпол-
няющаяся с частотой 2 Гц и поток вывода
данных, работающий как фоновая задача
и передающий данные, когда нет других
вычислительных задач.
Требования к схеме управления сле-
дующие:
–
управление скоростью вращения
мотора (частота обновления: 1 кГц);
–
прием с клавиатуры команд управ-
ления мотором, обновления дисплея;
–
управление простым дисплеем, с
обновлением 2 раза в секунду;
–
передача данных по порту RS-232 в
периоды времени, свободные от выпол-
нения других задач.
Определение относительных
приоритетов потоков. Когда опре-
делены основные потоки приложения,
надо установить их относительные при-
оритеты (см. табл. 1). Так как этот при-
мер системы управления — система
реального времени (есть жесткие вре-
менные параметры выполнения крити-
ческих операций), выполнение потоков
должно подчиняться приоритетам. В
данном примере есть один поток жест-
кого реального времени — алгоритм
управления мотором, который должен
выполняться с частотой 1 кГц. Также в
системе есть задачи мягкого реального
времени. Обновление дисплея с часто-
той 2 Гц — задача мягкого реального
времени. Обработка сигналов с клавиа-
туры — также задача мягкого реально-
го времени, но поскольку это — основ-
ной способ внешнего управления, у
задачи приоритет должен быть выше,
чем у обновления дисплея. Поток выво-
да наружу — фоновый, выполняется
Таблица 1. Приоритет задач
Задача
Частота
прерываний
Приоритет
Периодическая
или
апериодическая
Механизм
активации
Управление
электродвигателем
1 кГц
1
Периодическая
Аппаратное
прерывание
Управление
клавиатурой
5Гц
2
Апериодическая
Аппаратное
прерывание
Управление дисплеем
2Гц
3
Периодическая
Программное
прерывание
Вывод данных через
по рт
Фоновая задача
4
Апериодическая
Цикл бездействия
(выполняется в
фоновом режиме)

64
В
с
т
р
а
и
В
а
е
м
ы
е
с
и
с
т
е
м
ы
www. elcp.ru
только когда нет других работающих
задач.
Использование аппаратных пре-
рываний. Система управления двигате-
лем разрабатывается с использованием
аппаратных прерываний для контроля
потока управления двигателем. У пре-
рываний время переключения контек-
ста ниже, чем у переключения контек-
стов потоков, и прерывания могут быть
генерированы таймером процессора.
Приоритет задач в примере схемы управ-
ления мотором показан в таблице 1. Это
редкий пример монотонного распреде-
ления приоритетов: чем короче период
потока, тем выше его приоритет. Вместе
с приоритетами, описывается механизм
активации задач. Поток управления дви-
гателем с высшим приоритетом исполь-
зует аппаратное прерывание для запуска
исполнения. Аппаратные прерывания
имеют наибольший приоритет при пла-
нировании в большинстве ОСРВ. Работы
с клавиатурой также будет использовать
аппаратное прерывание, но его приори-
тет будет ниже, чем у прерывания управ-
ления двигателем. Поток управления дис-
плеем будет использовать программное
прерывание для обновления дисплея с
частотой 2 Гц. Задача с низшим приори-
тетом — вывод данных — будет рабо-
тать в непрерывном цикле в фоне, пока
не работают другие потоки с высшим
приоритетом.
Периодичности потоков. Поток
управления мотором — периодический.
Как и многие приложения цифровой
обработки сигналов, он обрабатывает
данные с некоторой периодичностью,
в данном случае — с частотой 1 кГц.
Рассматриваемый пример — система с
несколькими периодическими опера-
циями, в том числе управление мото-
ром и работа с дисплеем. Эти пото-
ки работают с разными скоростями.
ОСРВ для ЦОС позволяют одновремен-
ную работу нескольких периодических
потоков. Разработчик должен запро-
граммировать таймер процессора
таким образом, чтобы при наступле-
нии момента включения потока гене-
рировалось прерывание. Большинство
ОСРВ имеют стандартный диспетчер
таймеров и соответствующие функции
интерфейса для настройки параметров
таймеров.
заключение
Сложность ОСРВ возрастает. В то
время как программисты ЦОС пере-
ходят от модели «программирования в
малом», когда приложение ЦОС выпол-
няет одну задачу, к «программирова-
нию в большом», когда приложение
выполняет несколько сложных задач,
задача оптимального распределения
системных ресурсов становится все
более сложной. ОСРВ обеспечивает
необходимый уровень абстракции от
сложности систем. ОСРВ может быть
сконфигурирована разработчиком
ЦОС так, чтобы планировать зада-
чи в системе на основе набора пра-
вил, обрабатывать внешние события
быстро, эффективно распределять и
управлять системными ресурсами.
Коммерческие ОСРВ для ЦОС удобны
и полезны для разработчиков. Они
поставляются уже отлаженными, с
хорошей документацией и инструмен-
тальной поддержкой. Они оптимизи-
рованы, чтобы обеспечивать минимум
собственного потребления ресурсов
и максимум производительности для
ключевых функций, таких как пере-
ключение контекстов и обработка пре-
рываний.
Наиболее популярные ОСРВ для
ЦОС используют вытесняющие поли-
тики планирования с приоритетами.
Системы, основанные на таком подхо-
де к планированию, популярны в обла-
сти задач реального времени потому,
что они более легко анализируются,
чем более сложные механизмы плани-
рования.
Литерат ура
1. Robert Oshana. Real-Time Operating
Systems for DSP// www.dspdesignline.com/howto/
199703749;jsessionid=PBNP00WGKAQVCQSNDLPS
KH0CJUNN2JVN?pgno=1.

102
в
с
т
р
а
и
в
а
е
м
ы
е
с
и
с
т
е
м
ы
www. elcp.ru
В этой части рассмотрены основные проблемы, возникающие при реа-
лизации многозадачных систем и способы разделения общих ресурсов
в многозадачных системах. В статье описаны способы синхронизации
общих ресурсов, а также и другие формы синхронизации задач.
ОПераЦиОНые системы реаЛЬНОГО
времеНи ДЛЯ ЦиФрОвОЙ
ОБраБОтКи сиГНаЛа. Часть 2
1
РобеРт ошана (RobeRt oshana), DSP DesignLine
Взаимная блокиРоВка
Одна из обычных проблем — взаим -
ная блокировка (или deadlock), также
известная как «смертельные объятия»
(deadly embrace). Взаи мная блокиров -
ка — ситуация, в которой две про-
граммы, использующие один ресурс, не
позволяют друг другу получить доступ
к ресурсу, что приводит к нарушению
работы обеих программ. В ранних ОСРВ
в каждый момент времени могла выпол-
няться только одна программа. В такой
системе все ресурсы всегда доступны
для единственной запущенной програм-
мы, и таким образом блокировка невоз-
можна. С развитием ОСРВ они стали
поддерживать разделение процессор-
ного времени и чередование выполне-
ния нескольких программ, появились
системы с динамическим распределени-
ем ресурсов. В таких системах програм-
ма или задача могла запросить ресурс
уже после того, как она была запущена.
Возникла проблема взаимной блоки-
ровки в некоторых случаях, выводящая
систему из строя несколько раз в тече-
ние рабочего дня.
Следующий сценарий и ллюстрирует
возникновение взаимной блокировки и
ее связь с распределением ресурсов:
–
программа 1 запрашивает ресурс A
и получает доступ к нему;
–
программа 2 запрашивает ресурс B
и получает доступ к нему;
–
программа 1 запрашивает ресурс B
и становится в очередь, ожидая освобож-
дения ресурса B;
–
программа 2 запрашивает ресурс A
и становится в очередь, ожидая освобож-
дения ресурса A;
–
теперь ни та, ни другая програм-
ма не может продолжать выполнение
пока другая не освободит ресурс.
Операционная система не знает, какие
действия предпринять. В данной ситуа-
ции единственный выход — принуди-
тельно остановить одну из программ.
ПРедПосылки к ВозникноВению
блокиРоВки
Для возникновения ситуации вза-
имной блокировки должны возникнуть
следующие условия:
1. Взаимоисключающий доступ —
только одна задача может использовать
ресурс в каждый момент времени.
2. Несколько ожидающих задач —
должно быть несколько задач, удержи -
вающих ресурсы в ожидании других.
3. Циклическое ожидание — зада-
чи, удерживающие требующиеся дру-
гим ресурсы, выстроены в циклическую
цепочку.
4. Отсу тс твие принудительного вытес-
нения — ресурс может быть освобож-
ден только добровольно, занявшей его
задачей.
К сожалению, эти предпосылки
естественным образом выполняют-
ся практически в любой динамической
многозадачной системе, в том числе
и во многих ОСРВ для встраиваемых
систем. «Неопределенное откладывание»
(Indefinite Postponement) — это еще одно
состояние системы, при котором задача
не может получить доступ к ресурсу
потому, что другие задачи постоянно
перехватывают ресурс раньше. Такое
состояние также называют «голодани-
ем» или блокировкой (lockout).
как избежать Взаимной
блокиРоВки
Существуют две базовые стратегии
исключения ситуации взаимной блоки-
ровки. «Тяжелые» ОС общего назначения
обычно сами предотвращают взаимную
блокировку. Компактные ОСРВ, напротив,
подразумевают, что работу по исключе-
нию блокировок возьмет на себя про-
граммист. Некоторые ОСРВ способны
справиться с взаимной блокировкой без
участия программиста — либо самосто-
ятельно детектируя опасные ситуации и
разрешая их, либо отказывая в запросах,
которые могут приводить к блокиров-
кам. Такой подход сложен, поскольку в
общем случае обнаружить блокировку
сложно. Экстремальный подход — пере-
загрузка системы. Другой способ —
откат к состоянию до возникновения
блокировки. В общем случае, детекти -
рование блокировок более уместно для
ОС общего назначения, чем для систем
реального времени. Наиболее грубый
способ обнаружения и устранения бло-
кировок — использование сторожевого
таймера. В случае блокировки таймер
досчитает до своего предела (обнаруже-
ние блокировки) и перезагрузит систе-
му (устранение). Как запасной вариант
разрешения ситуаций для очень ред-
ких или недиагностируемых блокировок
такой способ приемлем.
Рассмотрим ОСРВ, динамически
определяющую ситуацию, в которой
предоставление ресурса может при-
вести к небезопасному состоянию.
Стратегия избегания ситуации взаим-
ной блокировки подразумевает, что
ОСРВ реализует алгоритм, который
допускает возникновение всех четырех
предпосылок, но при этом гарантиру-
ет, что система никогда не войдет в
состояние блокировки. При распреде-
лении ресурсов ОСРВ должна динами-
чески исследовать состояние ресурсов
и действовать, исходя из возможности
возникновения блокировки. Состояние
ресурсов подразумевает количество
доступных ресурсов, количество заня-
тых ресурсов и максимальную потреб-
ность в ресурсах для каждого при-
ложения.
Алгоритм избегания блокировок
должен не просто исключать воз-
можность возникновения состояния
блокировки — он должен исключать
возможность возникновения любых
небезопасных состояний. «Безопасное»
состояние — это состояние, в котором
система может выделить ресурсы каж-
1
Часть 1 напечатана в «Электронные компоненты» No5.

в
с
т
р
а
и
в
а
е
м
ы
е
с
и
с
т
е
м
ы
103
электронные компоненты No7 2008
дой задаче (максимальное количество,
которое задача может потребовать) в
некотором порядке и при этом избежать
блокировки. Следующий пример помо-
жет прояснить разницу. Предположим,
есть 12 блоков памяти, которые могут
быть распределены между задачами (см.
табл. 1). Такое состояние будет небезо-
пасным: два блока памяти все еще оста-
ются свободными, но задача 1 и задача 3
могут перейти в состояние взаимной
блокировки — и не смогут получить все
ресурсы, которые потребуются, даже
если задача 2 выполнится и освободит
еще два блока.
В таблице 2 приведен пример без-
опасного состояния: свободны три
блока памяти, следовательно, может
быть выполнена задача 2. Тогда Задача 1,
сможет использовать два блока, осво -
божденные задачей 2, и три свободных.
А после ее завершения сможет выпол-
няться и задача 3, используя освобож-
денные задачей 1 ресурсы.
Целостность Разделенных
РесуРсоВ
Вторая опасность параллельного
программирования — возможность
повреждения данных. Когда два или
более чередующихся потока пытают-
ся изменить однуи ту жепеременную,
или как-либо еще изменить общий
ресурс, они могут мешать друг другу,
искажая значение переменной или
состояние общего ресурса. В качестве
примера рассмотрим систему ЦОС со
следующими характеристиками:
–
память разделена между задачами;
–
архитектура типа загрузка-
сохранение (Load/Store), распростра-
ненная в настоящее время в сигнальных
процессорах;
–
ОСРВ с вытесняющей многозадач-
ностью;
–
в системе работают две задачи, T1
и T2 (задача T2 имеет приоритет выше,
чем T1);
–
обе задачи увеличивают общую
переменную X на единицу.
Для корректной работы любая опе-
рация по изменению общего ресурса
должна проводиться единой транзак-
цией — так, чтобы ее нельзя было
прервать до окончания. Участки кода
или последовательности выражений,
которые должны выполняться после-
довательно и неразрывно, называются
критическими секциями. Есть и другой
подход к решению проблемы. Вводится
ограничение — переменная, которая
может использоваться несколькими
задачами, может быть использована
или изменена только одним потоком в
каждый момент времени. Иными сло-
вами, в тот момент, когда какой-либо
поток изменяет переменную, для дру-
гих потоков исключена возможность
доступа к ней. Такой принцип доступа
или тип синхронизации данных назы-
вается взаимоисключающим доступом
(mutual exclusion).
Таблица 1. Пример небезопасного состояния
Процесс
Использует блоков памяти Может использовать (максимально)
Задача 1
5
10
Задача 2
2
4
Задача 3
3
9
Таблица 2. Пример безопасного состояния
Процесс
Использует блоков памяти Может использовать (максимально)
Задача 1
5
10
Задача 2
2
4
Задача 3
2
9

104
в
с
т
р
а
и
в
а
е
м
ы
е
с
и
с
т
е
м
ы
www. elcp.ru
синхРонизаЦия задач
для РеализаЦии
Взаимоисключающего достуПа
Есть несколько возможных способов
обеспечения синхронизации. Один из
возможных подходов — отключение
прерываний, при этом переключение
контекста становится невозможным.
Остается только возможность сраба-
тывания немаскируемых прерываний,
которые используются в ситуациях,
когда произошло (или может произой-
ти) что-то серьезное — например, пере-
запуск процессора. Следует учитывать,
что такой способ работает, только если
в системе всего один процессор.
Другой аппаратно-зависимый под-
ход — это использование недели-
мой инструкции для записи старого
состояния бита перед его изменени-
ем. Некоторые сигнальные процессоры
имеют специальные инструкции про-
верки и установки бита. Эта инструкция
считывает значение бита памяти, уста-
навливает бит состояния в соответствии
со значением проверенной ячейки
памяти и затем записывает в нее едини-
цу. Такая команда группирует несколько
операций с памятью в одну недели-
мую операцию, что позволяет избежать
проблемы «вклинивания» прерывания
между операциями чтения и изменения
и сбоя синхронизации данных.
При использовании взаимоисклю -
чающего доступа в каждый момент
времени только один процесс может
выполняться в критической секции (то
есть — программный счетчик указывает
на адрес в критической секции только
для одного из процессов). Если про-
цессов, выполняющихся в критической
секции, нет, и какой-то из процессов
хочет приступить к ее выполнению —
он может участвовать в принятии реше-
ния о доступе в критическую секцию.
Системы реального времени для
управления доступом используют
механизмы, называемые семафорами.
Семафор — это переменная синхрони-
зации, которая принимает положитель-
ные целые значения.
Взаимоисключающий
достуП ПРи Помощи контРоля
ПРеРыВаний
Один из подходов к реализации вза-
имоисключающего доступа — не допу-
стить прерывания задачи, использую-
щей общий ресурс или выполняющейся
в критическом сегменте программы.
Один из способов — отключение пре-
рываний. Программист может отклю-
чить прерывания перед переходом в
критический сегмент и включить их
обратно после выхода из критическо-
го сегмента. У такого подхода есть и
несколько существенных недостатков.
Отключение прерываний отключает в
системе и возможность принудитель-
ного вытеснения задач. Это может
негативно повлиять на производитель-
ность системы. Чем больше времени
отнимет выполнение критического
сегмента с отключенными прерыва-
ниями, тем больше увеличится время
реакции системы. Если программист
может отключать прерывания произ-
вольно, он может забыть включить их
после завершения критического сег-
мента. Все это приводит к тому, что
сбои в системе становятся неотслежи-
ваемыми. Такой процесс способствует
накоплению ошибок и, в отсутствие
должной дисциплины программирова-
ния, может привести к существенным
проблемам при интеграции и отладке.
ОСРВ предоставляют программисту
инструменты для работы с критиче-
скими сегментами без обращения к
системным прерываниям.
Взаимоисключающий достуП с
одним семафоРом
В простейшей форме семафор — это
флаг безопасности, сигнализирующий,
что ресурс заблокирован, но надо пом-
нить, что «семафор», как правило, озна-
чает нечто более сложное, чем простой
флаг, обеспечивающий цело стно сть при
переключении потоков. Служба сема-
форов, предлагаемая многими опера-
ционными системами, это специальная,
более сложная форма семафоров, кото -
рая автоматически приостанавливает
ожидающий процесс, если запрошен-
ный ресурс не занят.
Наиболее простая технология син-
хронизации в критической секции
называется активным ожиданием (busy
waiting). В этом случае задача устанав-
ливает и проверяет общую перемен-
ную (простой семафор), которая служит
флагом для обеспечения синхрониза-
ции. Этот метод также называется спин-
блокировкой. Чтобы сигнализировать
об использовании ресурса, задача
выставляет флаг и продолжает выпол-
нение. При ожидании ресурса задача
проверяет значение флага. Если значе-
ние равно 0 — то задача продолжает
работу с использованием ресурса. Если
значение равно 1 — то есть, ресурс уже
используется — задача будет проверять
его состояние опять. Недостаток актив-
ного ожидания — трата процессорного
времени на проверку состояния флагов.
Если в состоянии ожидания находится
более одной задачи, построение оче-
реди задач становится очень сложным.
Чтобы работать корректно, ожидающая
задача должна проверять состояние
флага и выставлять его, если ресурс
доступен, при помощи одной недели-
мой операции. Современные архитекту-
ры обычно включают инструкцию, ори-
ентированную на такую операцию.
Взаимоисключающий достуП с
исПользоВанием блокиРующих
семафоРоВ
Блокирующий семафор — это неот-
рицательная целая переменная, кото -
рая может быть использована с такими
функциями ОС, как Wait() — ожидание,
и Signal() — сигнал, для реализации раз-
личных типов синхронизации.
ОС гарантирует, что операции ожи-
дания и сигнала неделимы. Две задачи,
выполняющие операции ожидания и
сигнала с одним семафором, не могут
взаимодействовать друг с другом. Также
операционная система гарантирует,
что операции с семафором не могут
завершиться неудачно. Когда задача
ждет доступа на блокирующем сема-
форе, система выполняет следующие
действия:
1. Задача переходит к ожиданию.
2. Происходит вызов операционной
системы.
3. Задача о свобождает процессор.
4. Задача помещается в очередь
приостановленных задач для данного
семафора.
5. Операционная система запускает
другую задачу.
6. В какой-то момент времени для
данного семафора запускается опера-
ция сигнала.
7. ОС выбирает одну из приостанов-
ленных задач, ожидающих сигнала на
семафоре и запускает ее на выполнение.
Значение семафора увеличивается толь-
ко в том случае, когда нет приостанов-
ленных ожидающих задач.
Планировщик ОСРВ не сможет
выгрузить задачу, пока выполняется
операция ожидания или сигнала. ОСРВ
также может отключать прерывания,
чтобы внешние события не могли
прервать выполнение операций. В
многопроцессорных системах для
блокирования семафора необходи-
мо использование неделимых команд
перестановки или тестирования
и установки. Семафоры — это про-
граммный инструмент, они не являют-
ся элементами аппаратного обеспече-
ния. Семафоры обладают следующими
положительными свойствами.
1. Независимость от платформы —
семафоры реализованы программным
способом и являются одним из стан-
дартных механизмов синхронизации в
ОСРВ для цифровой обработки сигнала.
2. Простота — семафоры относи-
тельно просты в использовании, они
задействуют операции запроса и осво-
бождения, которые обычно являются
стандартными вызовами программного
интерфейса ОСРВ.
3. Корректность системы легко опре-
деляется — это очень важно для слож-
ных ОСРВ.

в
с
т
р
а
и
в
а
е
м
ы
е
с
и
с
т
е
м
ы
105
электронные компоненты No7 2008
4. Возможность работы с нескольки-
ми процессами — использование сема-
форов не ограничивается сложностью
системы.
5. Различные критические сегмен-
ты могут быть защищены различны-
ми семафорами — это существенно
снижает реактивность системы. Если
все важные сегменты кода защищены
единственным семафором, очередь
ожидающих задач будет неприемлемо
длинной с точки зрения общего време-
ни реакции системы.
6. Возможность использовать один
семафор для обслуживания нескольких
ресурсов — если необходимо защищать
два или более однотипных системных
ресурсов, то для работы с ними может
использоваться «считающий» семафор.
Взаимоисключающий достуП и
Разделяемые РесуРсы
Все рассмотренные выше технологии
синхронизации обладают общим недо-
статком — они требуют от программи-
ста соблюдения определенной дисци-
плины программирования при каждом
обращении к ресурсу. Более надежный
способ решить проблему взаимных бло-
кировок — использование разделяе-
мых ресурсов. Многие ОС предлагают
высокоуровневые разделяемые структу-
ры данных, включая очереди, буферы и
конвейеры данных. Они надежно защи-
щены, поскольку доступ к ним возмо-
жен только через синхронизированные
службы операционной системы.
Циклический буфер или круговая
очередь. Часто информация может
передаваться между задачами без
использования синхронизации в явном
виде, при помощи циклического буфера.
Такой буфер представляет собой коль-
цевую замкнутую структуру. Данные
загружаются в точке, называемой «хво-
стом» буфера и считываются в точке,
называемой «головой». Преимущество
такой структуры — неделимая опера-
ция, буфер используется только одним
процессом для записи и одним — для
чтения, так что синхронизация данных
не требуется. Как и с любым конечным
(ограниченным) буфером, и считываю-
щий, и записывающий процессы должны
выполнять следующие требования:
–
задача, помещающая данные
в буфер (производитель), не должна
пытаться поместить данные в заполнен-
ный буфер;
–
задача, считывающая данные
(потребитель), не должна пытаться
извлечь данные из пустого буфера.
Двойная буферизация. Часто называ-
ется пинг-понг-буферизацией — исполь-
зование двух одинаковых буферов, при
котором буфер, в который производит-
ся запись, и буфер, из которого про-
изводится чтение, меняются ролями.
Переключение производится аппаратно
или программно. Двойная буферизация
используется во многих системах теле-
метрии, дисковых контроллерах, гра-
фических интерфейсах, навигационном
оборудовании, робототехнике и других
приложениях.
Конвейеры данных. В качестве при-
мера поддержки передачи данных между
заданиями в приложениях реального
времени, операционная система DSP/
BIOS предлагает модули ввода-вывода
для обмена данными между потоками (и
обработчиками прерываний), использую-
щие концепцию конвейеров. Конвейер —
это объект с двумя сторонами: «хвостом»,
используемым передающим процессом,
и «головой», использующейся принимаю-
щим процессом. Также существуют функ-
ции оповещения, вызываемые при готов-
ности системы к передаче данных. Буфер
данных, используемый в этом протоколе,
может быть разделен на фиксированное
количество кадров (nframes) определен-
ного размера (framesize).
дРугие тиПы синхРонизаЦии
Хотя основной причиной синхрони-
зации действий различных задач являет-
ся сохранение целостности общих дан-
ных, есть и другие ситуации, в которых

106
в
с
т
р
а
и
в
а
е
м
ы
е
с
и
с
т
е
м
ы
www. elcp.ru
требуется синхронизация. Иногда одна задача должна ждать
завершения других, прежде чем продолжить выполнение
(такая ситуация называется рандеву). Иногда задача может
продолжать выполнение только в случае выполнения опреде-
ленных условий.
синхронизация задач — рандеву. Для синхронизации
задач часто используются семафоры. Рассмотрим случай,
когда на сигнальном процессоре исполняются две задачи,
имеющие одинаковый приоритет. Если задача A приходит в
состояние готовности раньше, чем B, то она выставляет сема-
фор, и задача B будет отложена. Если задача B имеет приоритет
выше A, и задача B приходит в состояние готовности раньше,
чем A, то задача A может быть вытеснена при освобождении
семафора при помощи операции Post.
Условная синхронизация. Обычно используется в тех
случаях, когда задача пытается выполнить операцию, кото-
рая возможна (с точки зрения алгоритма или безопасности
системы) только тогда, когда другая задача выполнила какое-
либо действие или находится в определенном состоянии.
Примером синхронизации такого типа является использова-
ние буфера. Буфер используется для развязки двух задач, одна
из которых производит запись, а другая — чтение данных.
Использование буферной связки также известно как система
производитель—потребитель. Буфер может использоваться
для эффективного урегулирования колебаний скорости пере-
дачи данных между задачами и различий объемов блоков
данных производителя и потребителя, сохранения привязки
ко времени и переупорядочения данных.
заключение
Многозадачность имеет множество преимуществ при
разработке сложных систем реального времени. Тем не
менее, одна из значительных проблем многозадачности
состоит в том, что параллельные процессы часто нуждаются
в обмене данными (расположенными в структурах в разде-
ляемой памяти), а также в общих ресурсах, таких как встро-
енная память, порты ввода-вывода и прочие периферийные
устройства. Необходимо контролировать доступ к общим
данным и ресурсам — в противном случае может нарушить-
ся целостность данных, или аппаратный ресурс будет рабо-
тать некорректно. Действия, выполняемые параллельными
процессами, будут в конечном итоге зависеть от порядка, в
котором производится переключение задач. Это приводит
к неопределенности при исполнении, что неприемлемо для
систем реального времени — и что крайне сложно диагно-
стировать и исправить.
Ошибки параллелизма могут быть малозаметными и
непостоянными. Очень важно определять и синхронизиро-
вать все, что разделяется между задачами и потоками. В ОСРВ
эта задача решается более просто. ОСРВ для цифровой обра-
ботки сигналов обеспечивает взаимоисключающий доступ в
многопроцессорных системах, гарантируя, что критические
сегменты не будут исполняться более чем одним процес-
сом в один период времени. Такие сегменты кода получают
доступ к разделяемым переменным в общей памяти или к
разделяемому аппаратному обеспечению, такому как встро-
енная память или контроллер прямого доступа к памяти. То,
что действительно происходит внутри критического сегмен-
та, с точки зрения проблемы взаимоисключающего доступа
не важно. Для систем реального времени обычно предпо-
лагается, что такие сегменты относительно короткие, чтобы
уменьшить общее время реакции системы.
Семафоры в системах реального времени для ЦОС исполь-
зуются для двух основных задач: синхронизации задач и
управления ресурсами. ОСРВ для ЦОС должна реализовывать
механизм семафоров. За правильное распределение ресур-
сов отвечает программист, но семафор может использоваться
как главный инструмент управления ресурсами.
Новости микрокоНтроллеров
и DSP
|tIПРедлагает комПлект РазРаботки для ПРоЦес-
соРоВ oMaP35x | Компании Logic и Texas Instruments
выпустили комплект разработчика Zoom Medical
OMAP35x, предназначенный для медицинских приложе-
ний, в которых используются встраиваемые устройства
с расширенными функциями, например усовершенство-
ванные графические интерфейсы, интеллектуальные
приборы для обработки данных диагностики в реальном
времени, проводные и беспроводные устройства для
контроля состояния пациента, а также приборы в при-
ложениях для регистрации данных.
В комплект разработки входит процессор TI OMAP35x
с интегрированным ядром ARM Cortex-A8, цифровой сиг-
нальный процессор TMS320C64x+, 2D/3D-графический
процессор и видеоускорители. Модуль процессора
OMAP35x выполнен в форм-факторе SOM-LV Type III с
размерами 31 × 76,2 × 7,4 мм. Платформа поддерживает
Bluetooth 2.0 + EDR, 802.11b/g беспроводной Ethernet,
USB 2.0 OTG, 24-бит/пиксел контроллер TFT ЖКД и
четырехпроводной сенсорный экран. К числу поддер-
живаемых ОС относятся Linux, Windows CE и Green
Hills. Массовый выпуск комплекта разработчика Zoom
Medical OMAP35x (TMDXMEVM3503-L) произойдет в тре-
тьем квартале 2008 г.
www.russianelectronics.ru

114
М
и
к
р
о
к
о
н
т
р
о
л
л
е
р
ы
и
D
S
P
www. elcp.ru
В заключительной части статьи рассматриваются статистический
и динамический алгоритмы планирования. Описаны методы анализа
определения планируемости и способы решения некоторых проблем воз-
никающих при планировании. Статья представляет собой сокращенный
перевод фундаментального цикла статей [1].
операционные систеМы
реального вреМени для
цифровой обработки сигнала.
Часть 3
1
РобеРт ошана (RobeRt oshana), DSP Designline
ВВедение
В ОСРВ проверка факта, удовлетворя-
ет ли время выполнения задачи задан-
ным ограничениям, называется анализом
планируемости (schedulability analysis).
Существуют два основных метода плани-
рования — с фиксированными или стати-
ческими приоритетами и с динамически-
ми приоритетами. Многие коммерческие
ОСРВ поддерживают политики планиро-
вания с фиксированными приоритетами.
ПО, обеспечивающее реализацию такого
подхода, получается компактным, а пла-
нировщик быстрым и предсказуемым.
Большая часть работы по планированию
выполняется еще до запуска системы.
Но такой метод не в состоянии работать
с задачами, возникающими при работе
системы. Приоритет каждой задачи дол-
жен быть определен заранее и не может
измениться в ходе работы системы, если
только сама задача не изменит его.
Алгоритмы динамического планиро-
вания позволяют планировщику изме-
нять приоритет задачи, основываясь на
одном из нескольких алгоритмов или
политик планирования. Такой подход
более сложен и требует для реализа-
ции большего объема кода и приводит к
большим временным затратам при управ-
лении набором задач в системе ЦОС. Это
приводит к неопределенностям, которые
не приветствуются, особенно в системах
реального времени. Динамические алго-
ритмы планирования являются онлайно-
выми алгоритмами. Набор активных задач
изменяется в течение работы системы, и
приоритеты тоже могут изменяться.
СтатичеСкие политики
планиРоВания
Примерами статических политик
планирования являются частотно-
1
Части 1 и 2 опубликованы в ЭК No5 и No7 соответственно.
пропорциональное планирование (rate-
monotonic scheduling или RMS) и плани-
рование с учетом предельных сроков
выполнения (deadline momotonic
sheduling или DMS). При планиро-
вании RMS приоритет тем выше, чем
выше частота вызова (то есть, величи -
на, обратная периоду вызова) задачи.
Такой подход может быть реализован в
любой системе, поддерживающей пла-
нирование с фиксированными приори-
тетами, например, DSP/BIOS и VxWorks.
Частотно-пропорциональное планиро-
вание подразумевает, что предельный
срок выполнения (deadline) периодиче-
ской задачи совпадает с ее периодом.
Планирование с учетом предельных
сроков выполнения — это обобщение
частотно-пропорциональной политики
планирования. При таком подходе пре-
дельный срок выполнения задачи это
фиксированный момент времени отно-
сительно начала периода задачи. Чем
короче предельный срок выполнения,
тем выше приоритет задачи.
динамичеСкие политики
планиРоВания
Динамические алгоритмы планирова-
ния могут быть разделены на два основ-
ных класса. Первый использует подход,
который можно назвать динамическим
предварительным планированием. Он
удобен для систем, которые должны
динамически принимать новые задачи,
например, базовая станция беспровод-
ной связи. Такой подход объединяет гиб-
кость динамического и предсказуемость
статического принципов планирования.
При поступлении задачи, но перед нача-
лом ее выполнения, производится про-
верка — возможно ли составить рас-
писание выполнения задач, в котором
новая задача сможет выполняться вме-
сте с уже работающими.
Другой подход — метод максималь-
ных возможных усилий (dynamic best
effort apprоach), использует предельные
сроки выполнения задач для расста-
новки приоритетов. При использовании
такого планирования работающая задача
может в любой момент быть вытеснена.
Таким образом, гарантировать выпол-
нение задачи в пределах временных
ограничений невозможно — об этом
можно судить только когда наступит
предельный срок исполнения или когда
задача будет выполнена. Примерами
динамических best effort алгоритмов
являются планирование с приоритет-
ным выполнением задачи с ближайшим
предельным сроком и планирование с
наименьшим временем бездействия.
планиРоВание С пРиоРитетным
Выполнением задачи С
ближайшим пРедельным СРоком
Планирование с приоритетным выпол-
нением задачи с ближайшим предельным
сроком — Earliest deadline first (EDF) —
это вытесняющая политика с динами-
ческими приоритетами. В этом подходе
предельный срок выполнения — абсо-
лютный момент времени, к которому
должно завершиться выполнение задачи.
Предельный срок вычисляется при соз-
дании задачи. Планировщик ОС выбирает
для запуска задачу, у которой предельный
срок ближе всего. Задача с более ранним
предельным сроком вытесняет задачу с
более поздним предельным сроком.
планиРоВание С наименьшим
ВРеменем бездейСтВия
Планирование с минимальным без-
действием — это также вытесняющая

116
М
и
к
р
о
к
о
н
т
р
о
л
л
е
р
ы
и
D
S
P
www. elcp.ru
политика с динамическими приорите-
тами. Время бездействия задачи — это
абсолютный предельный срок выполне-
ния минус оставшееся до завершения
время работы задачи. Планировщик ОС
выбирает для запуска задачу с наимень-
шим временем бездействия. Задача с
меньшим временем бездействия вытес-
няет задачу с большим временем без-
действия. Такой подход максимизирует
минимальную задержку задач.
ВытеСняющее планиРоВание С
динамичеСкими пРиоРитетами
При использовании такого мето-
да динамического планирования, как
вытесняющее планирование с дина-
мическими приоритетами, приоритет
задачи может меняться и для разных
ее экземпляров, и в ходе выполнения
одного экземпляра. При таком подходе
задача с высшим приоритетом вытесня-
ет задачу с низшим приоритетом. Очень
немногие коммерческие ОСРВ под-
держивают эти методы планирования,
поскольку подобные системы сложно
анализировать с точки зрения детерми-
низма и соблюдения реального време-
ни. Поэтому далее мы сфокусируемся на
статических политиках планирования.
анализ поВедения
планиРоВщика В ВытеСняющих
СиСтемах
Системы с вытесняющей многоза-
дачностью используют алгоритмы пла-
нирования, аналогичные описанным
выше. Далее мы рассмотрим технологии
статического анализа задач в системах
цифровой обработки и методы опти-
мизации их выполнения. Будут описаны
три способа определения того, будет
ли определенный набор задач уклады-
ваться в предельные сроки — частотно -
пропорциональный анализ, анализ
времени завершения и анализ времени
отклика.
чаСтотно-пРопоРциональный
анализ
Частотно-пропорциональный ана -
лиз — rate monotonic analysis (RMA) —
определяет, будет ли группа задач, для
которых известен уровень загрузки
процессора, укладываться в предель-
ные сроки выполнения. Этот метод
предполагает использование вытесняю-
щих алгоритмов, основанных на учете
приоритетов. Такой подход подразуме-
вает независимое выполнение задач —
без обмена данными и синхронизации.
Задача о бладает следующими характе-
ристиками:
1. Все задачи периодические, каж-
дая задача выполняется с определенной
частотой и характеризуется периодом T.
2. Время выполнения задачи — C, то
есть время, в течение которого процес-
сор выполняет задачу в каждый период.
3. Использование — U, это соотно -
шение C/T. Задача считается планируе-
мой, если она может быть выполнена с
соблюдением всех ее предельных сро-
ков — то есть, задача завершает выпол-
нение прежде, чем завершается оче-
редной период. Группа задач считается
планируемой, если каждая ее задача
выполняется в свои предельные сроки.
RMA — математическое решение
проблемы планирования для перио-
дических задач с известным уровнем
использования. При этом предполага-
ется, что общий уровень использования
должен всегда быть меньше или равен
100%. В случае множества независимых
периодических задач алгоритм RMA
присваивает каждой задаче фиксиро-
ванный приоритет на основе ее перио-
да так, что чем меньше период, тем выше
приоритет. Для трех задач — T1, T2 и T3,
с периодами 5, 15 и 40 мс соответствен-
но, высший приоритет присваивается
задаче T1, затем задаче T2 и самый низ-
кий — T3. Отметим, что присвоение
приоритета не связано с важностью
задачи и тем, насколько выполнение
задачи в заданные сроки критично для
функционирования системы или для
задач пользователя.
Метод планирования RMA основан
на теореме предела использования.
Согласно этой теореме, множество из
N независимых задач, выполнение кото -
рых распланировано с помощью RMS,
всегда уложится в крайние сроки для
любых соотношений моментов запу-
ска задач, если общее использование
набора задач меньше определенного
уровня. В таблице 1 приведен гранич-
ный уровень использования для разных
количеств задач.
При гармоническом наборе задач
(периоды всех задач кратны друг другу)
частотно-пропорциональное планиро-
вание позволяет использовать пропуск-
ную способность процессора на 100%, и
при этом все задачи будут укладываться в
свои предельные сроки. Для гармониче-
ских задач справедлива теорема време-
ни завершения, которая гласит, что для
множества независимых периодических
задач, если каждая задача укладывает-
ся в предельный срок выполнения при
условии, что они все запущены одно-
временно, то задачи будут укладываться
в предельные сроки при любом сочета-
нии моментов старта. Примерами при-
ложений, задачи которых могут иметь
гармонические периоды, являются:
–
о бработка аудиосигнала;
–
видеозахват и обработка видео-
сигнала;
–
мониторинг температуры и скоро-
сти.
анализ ВРемени отклика
Альтернативный подход называется
анализом времени отклика. Он делит-
ся на 2 этапа. Первый — предсказа-
ние худшего случая времени отклика
для каждой задачи. Затем время откли-
ка сравнивается с требуемым сроком
выполнения. В анализе времени отклика
используется худший случай времени
отклика R — то есть времени, требуе-
мого для завершения работы задачи
после ее создания. Для этого анализа
будет подразумеваться та же модель с
независимыми задачами и допускающая
вытеснение задач:
Ri=Ci+Ii,
где: Ci — время выполнения задачи i;
Ii — максимальная задержка, вызывае-
мая другими задачами, или воздействие,
которое задача i может испытывать в
любой отдельный интервал времени от
t до t + Ri. Максимальное вмешательство
будет иметь место, если все задачи с
высшим приоритетом будут запущены
в то же время, что и задача i. Примеры
расчета приведены в [1].
задеРжки пРеРыВаний
Время, требуемое для обслуживания
прерывания, меняется в зависимости
от его источника. Обработка прерыва-
ний в большинстве случаев делится на
два шага — немедленное обслужива-
ние прерывания и планируемое обслу-
живание. Немедленное обслуживание
выполняется с уровнем приоритета пре-
рываний. Количество уровней приори-
тетов прерываний зависит от процес-
сора, например, семейство TMS320C55
поддерживает 32 прерывания с заранее
определенными (предопределенными)
приоритетами. Все приоритеты пре-
рываний выше, чем приоритеты задач,
и выше, чем приоритет планировщика.
Общая задержка обработки прерывания
в ЦПС — это время, которое процессор
тратит на выполнение текущей инструк-
ции, необходимых рутинных операций
и переход к обработчику прерываний
и диспетчеру прерываний в ядре. Затем
ядро отключает внешние прерывания.
Таблица 1. Пределы использования для различных
множеств задач
Количество задач
Предел
использования
1
1,0
2
0,828
3
0,779
4
0,756
5
0,743
6
0,734
7
0,728
8
0,72
9
0,72
Бесконечность
0,69

М
и
к
р
о
к
о
н
т
р
о
л
л
е
р
ы
и
D
S
P
117
электронные компоненты No9 2008
Также некоторое время может потре-
боваться для завершения неотложных
служебных процедур прерываний
высшего уровня, если таковые актив-
ны. Ядро также должно сохранить кон-
текст прерванного потока, определить
прерывающее устройство и получить
стартовый адрес процедуры обработки
прерываний. Суммарное время называ-
ется задержкой прерываний (interrupt
latency) и определяет оперативность
реагирования на внешние события
посредством механизма прерываний.
Многие ОСРВ обеспечивают приложе-
ниям возможность отслеживать момент,
когда прерывания включаются снова.
Процессор, таким образом, может
управлять скоростью, с которой обслу-
живаются внешние прерывания.
задеРжки пеРеключения
контекСта
В системе, основанной на задачах, на
переключение с одного потока на дру-
гой планировщик ОСРВ тратит опреде-
ленное конечное время. Эта задержка
называется задержкой переключения
контекста. Худший случай задержки
переключения контекста задачи — это
два действия планирования, одно при
начале исполнения задачи, другое по
завершении. При расчете предельного
использования для задачи необходимо
учитывать задержки переключения кон-
текста. В уравнении ниже они обозначе-
ны как CS и представляют общее время
переключения при переходе от одной
задачи к другой.
Ui = (Ci/Ti) + 2CSi.
Цель ОСРВ — поддерживать слагае-
мое 2CS на уровне много меньшем, чем
время выполнения задачи T1, обладаю-
щей наименьшим периодом в системе.
анализ более Сложных СиСтем
Модель, которую мы использовали
для определения планируемости задач
до сих пор, была относительно простой.
–
все задачи предполагаются пери-
одическими, с известными периодами;
–
предельный срок выполнения
задачи совпадает с ее периодом;
–
приоритеты задачам присваива-
ются пропорционально их частоте — то
есть, используется RMS-алгоритм;
–
задачи независимы друг от друга;
–
используется вытесняющая стра-
тегия планирования;
–
приоритеты приложения фиксиро-
ваны — то есть, являются статическими;
–
все дополнительные задержки,
возникающие в системе, включаются во
время выполнения задачи;
–
у всех задач фиксированное мак-
симальное время выполнения (для худ-
шего случая).
На практике в ОСРВ существуют как
периодические, так и апериодические
задачи. Апериодическая задача выпол-
няется один раз в течение некоторо-
го периода TА, который представляет
собой минимальный интервал времени
между событиями, активирующими зада-
чу. Время загрузки процессора CА — это
время выполнения задачи, вызванной
одним событием. Время использования,
таким образом, представляет собой худ-
ший случай и может быть гораздо мень-
ше реального. С точки зрения анализа
планирования, апериодическая задача
равносильна периодической с перио-
дом, равным TА, и временем выполнения,
равным CА.
Время отклика апериодической
задачи часто должно быть гораздо
меньше, чем минимальный интервал
поступления такой задачи. Например,
сигнал об ошибке может возникать
очень редко, но при этом он требует
оперативной реакции. Это противо-
речит предположению, что предель-
ный срок выполнения равен периоду.
Предельный срок должен быть меньше
периода. Это называется инверсией
частотно -пропорционального присво е-
ния приоритетов. Задача i, выполнение
которой распланировано RMS-методом,
может быть вытеснена из-за инверсии
пропорционального присвоения прио-
ритетов только один раз, так как имеет
меньший период. Как худший случай
инверсии приоритетов предполагает-
ся, что каждаязадача с низшим приори-
тетом tl блокируется один раз каждой
апериодической задачей.
DMs-алгоРитм планиРоВания
При использовании DMS-алгоритма
планирования приоритет тем выше, чем
короче предельный срок выполнения.
Приоритеты фиксированы и распределя-
ются до запуска приложения. Используя
статическую модель, можно доказать,
что это оптимальный алгоритм плани-
рования для случаев, когда предельный
срок выполнения меньше или равен
периоду задачи T. Крайний случай, когда
все предельные сроки равны периодам,
это частотно-пропорциональное плани-
рование.
Алгоритм DMS проверяет, удовлет-
воряют ли все задачи своим предель-
ным срокам выполнения при наихуд-
ших условиях (синхронизации моментов
старта задач). Худший случай времени
отклика включает задержки каждой
задачи, вызванные вытеснением их дру-
гими задачами, с высшим приоритетом.
Этот алгоритм может быть легко рас-
ширен, с включением других факторов
задержки, таких как время переключе-
ния контекста, блокировки из-за ожи -
дания системных ресурсов и прочие
задержки системы.
СРаВнение динамичеСкого и
СтатичеСкого планиРоВания
Как было показано выше, частотно-
пропорциональное планирование —
оптимальная статическая политика
планирования. Тем не менее, некото-
рые наборы задач, не планируемые при
помощи RMS, могут быть расплани-
рованы при помощи динамических
стратегий. Пример — набор задач,
в которых предельный срок выпол-
нения короче, чем период задачи. В
этом примере мы продемонстрируем
набор задач, который может быть рас-
планирован с использованием поли-
тики DMS, но не при помощи RMS.
Рассмотрим набор задач, указанных
в таблице 2. Диаграмма выполнения
задач, распланированных при помощи
DMS, показана на рисунке 1. Все зада-
чи удовлетворяют предельным срокам
выполнения.
Теперь рассмотрим тот же набор
задач, но на этот раз приоритеты будут
распределены пропорционально часто-
те задачи, как показано в таблице 3.
Временная диаграмма выполнения
задач, распланированных с использо-
ванием RMS, показана на рисунке 2.
Обратите внимание, в таком случае зада-
ча 1 не планируема — не укладывается
Рис. 1. Пример планирования при помощи DMS алгоритма

118
М
и
к
р
о
к
о
н
т
р
о
л
л
е
р
ы
и
D
S
P
www. elcp.ru
в предельные сроки выполнения, хотя
выполняется в соответствии со своим
периодом.
планиРоВание и СинхРонизация
задач
Выше рассматривались только
независимые задачи, но такое усло-
вие применимо только к очень огра-
ниченному кругу задач. Практически
во всех приложениях задачи взаимо-
действуют друг с другом. Требования
синхронизации задач привносят свои
проблемы. Рассмотрим следующий
сценарий — задача входит в крити-
Таблица 3. Пример планирования при помощи RMS-алгоритма
Задача Предельный
ср ок
Время завер-
шения
Период Использование Приоритет
T1
5мс
3мс
20 мс
0,15
3
T2
7мс
3мс
15 мс
0,20
2
T3
10 мс
4мс
10 мс
0,40
1
T4
20 мс
3мс
20 мс
0,15
4
ческую секцию (т.е . требует исключи-
тельного доступа к ресурсу, напри-
мер, к устройству ввода/вывода или
структуры данных). Задача вытесняет-
ся другой, обладающей высшим при-
оритетом, которая требует доступа к
тому же ресурсу. Но задача с высшим
приоритетом блокируется до выпол-
нения задачи с низшим приоритетом.
Задача с низшим приоритетом может
быть блокирована другими задачами с
высоким приоритетом и так до беско-
нечности. Ситуация, в которой задача
с высшим приоритетом должна ждать
выполнения задачи с низшим прио-
Таблица 2. Пример планирования при помощи DMS-алгоритма
Задача
Предельный
ср ок
Время
завершения Период Использование Приоритет
T1
5мс
3мс
20 мс
0,15
1
T2
7мс
3мс
15 мс
0,20
2
T3
10 мс
4мс
10 мс
0,40
3
T4
20 мс
3мс
20 мс
0,15
4
ритетом называется инверсией при-
оритета (priority inversion). Этот слу-
чай довольно подробно рассмотрен
в [1, 2].
заключение
Многие ОСРВ используют стати-
ческие алгоритмы планирования,
потому что они просты в реализа-
ции, их легко понять и поддержи-
вать, имеется широкий выбор техно-
логий их анализа. Для определения
планируемости системы разработ-
чики приложений цифровой обра-
ботки сигналов могут использовать
частотно-пропорциональный анализ.
Если система не планируема, то воз-
можен анализ проблем, связанных с
блокированием разделяемых ресур-
сов. Такой анализ особенно полезен
для первичной оценки работоспо-
собности системы, а его результаты
могут быть использованы для пере-
работки системы задач и доступа к
ресурсам. Большинство существую-
щих ОСРВ, такие как VxWorks, VRTX,
а также специализированные ОСРВ
для ЦОС, такие как DSP/BIOS, исполь-
зуют частотно-пропорциональное
планирование вместе с каким-либо
вариантом протокола наследования
или ограничения приоритета, чтобы
ограничить блокирование ресурсов и
инверсию приоритетов. Несмотря на
эффективность такого подхода, сле-
дует иметь в виду ограничения стати-
ческого планирования, включающие
неэффективную обработку неперио-
дических вычис лений и негармони-
ческих периодов, а также требование
распределения ресурсов на основа-
нии оценки худшего случая.
Литература
1. Robert Oshana. Real-Time Operating
Systems for DSP, part 8//http://www.dspdesignline.
com /h owt o/showA rticle . jhtml?articleID =199703749.
2. Игорь Алексеев. Операционные систе-
мы реального времени//Электронные компо-
ненты No5, 2008 .
Рис. 2. Тот же пример, нос использованием RMS — задачане укладывается в предельный срок выполнения
Резюме с указанием вакансии присылать
по адресу: elecom@ecomp.ru,
тел.: (495) 234-77-57, факс: (495) 620-93-56
требования к кандидату
РУкоВодитель отдела пРодаж
опыт работы в сфере продаж (услуги). опыт руководства коллективом.
30—45 лет, в/о. разговорный английский язык.
Личные качества: коммерческий ск лад мышления, энергичность,
коммуникабельность.
Условия: стартовая з/п 60 000—80 000 руб., тк р ф, мед. страховка, дотация
на занятия спортом. дружный коллектив, стабильность и надежность.
Место работы: м. павелецкая, м. пролетарская.
издательский дом приглашает на работу сотрудника на должность
руковод ите ль отд ел а прод аж.
Обязанности: подготовк а коммерческих предложений для клиентов,
координация работы менеджеров по продажам, переговоры с ключевыми
клиентами.