Работа с временными интервалами и организация вычислительного процесса. Технологии RTST и REAL

Работа с временными интервалами

В системах реального времени часто возникает ситуация, когда текущий процесс должен быть задержан на определенный период времени. Чаще всего такая ситуация возникает, когда процесс должен дождаться окончания работы какого-то внешнего устройства. Задержку на определенное время осуществляет оператор delay m, где m – количество каких-то единиц времени, например, миллисекунд.

Мы уже много лет применяем следующую реализацию оператора delay. Процесс, в котором исполнялся этот оператор, приостанавливается и ставится в очередь задержанных процессов. Эта очередь упорядочена по времени ожидания. Например, пусть p1 и p2 ждут 10 мсек, p3, p4, p5 – 30 мсек, p6, p7 – 100 мсек. Тогда в очереди задержанных процессов первым узлом будет узел с временем ожидания 10, к которому "заплетены" p1 и p2, за ним следует узел с ожиданием 30, к которому "заплетены p3, p4 и p5, а последним узлом в очереди задержанных процессов будет узел с временем ожидания 100 с "заплетенными" к нему p6 и p7.

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

Очевидной оптимизацией является хранение в узлах не абсолютных значений времени ожидания, а нарастающих итогов, например, в нашем примере, не 10, 30, 100, а 10, 20, 70. Тогда каждую миллисекунду надо вычитать 1 только из первого узла. В УВК "Самсон" мы ввели так называемое "мягкое" прерывание: каждую миллисекунду мы вычитали 1 из верхушки списка задержанных процессов на микропрограммном уровне и только при обращении верхушки в 0 реально вызывалась функция ОС.

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

В начале восьмидесятых годов ХХ-го века мы неожиданно обрели конкурента в лице одного пензенского завода. Их бывший директор стал большим начальником в области правительственной связи и, как это принято в нашей стране, стал "сливать" им все заказы с большими деньгами, хотя раньше они никогда телефонных станций не делали. Им за малые АТС давали большие деньги, чем нам за большие АТС, им разрешали использовать импортные микросхемы, нам – нет и т.д. Так вот, они даже с лучшими американскими микропроцессорами того времени хронически не укладывались во временные ограничения. Разобраться, в чем дело, причем втайне от большого начальника, поручили нам. Среди многих неграмотных решений самым несуразным оказалась реализация оператора delay. Каждую миллисекунду они приостанавливали текущий процесс, заходили во все процессы (т.е. возобновляли их), проверяли, нет ли там оператора delay, если есть – вычитали 1 и снова сворачивали процесс. Процессов было больше 1000, свертка-развертка у них занимала 500-600 команд — понятно, куда уходило время. В результате "разбора полетов" четырех ведущих разработчиков из Пензы прислали к нам на стажировку на месяц, но мат-мех за месяц не закончишь. Хотя свою АТС они все-таки сдали – с пятилетним опозданием.

Другой пример связан с французской АТС МТ/20. В 1979 году СССР официально купил лицензию на право производства этой АТС (что было редкостью в то время). В Уфе построили большой завод, и после многих трудностей, связанных, в основном, с попытками "улучшить" и "советизировать" готовую АТС, наладили массовое производство. Даже к началу XXI века это была самая массовая цифровая АТС в нашей стране (более 3 млн. абонентов). МТ/20 проживет еще 15-20 лет, однако ее центральная ЭВМ 3202 (два больших шкафа) первой не выдержала испытания временем. Уже не выпускаются микросхемы, используемые в этой ЭВМ, давно забыты технологические средства, применявшиеся при ее разработке, наконец, не осталось и инженеров, умеющих ее налаживать. Понятно, что основной ценностью МТ/20 является ее программное обеспечение. Заводчане постепенно модернизировали основные аппаратные блоки МТ/20, прежде всего, блоки памяти, вызывавшие много нареканий, уменьшили массогабариты и энергопотребление, но не смогли существенно модернизировать ПО.

По заказу завода мы разработали новую ЭВМ, идентичную по архитектуре и системе команд старой 3202. Главной задачей было обеспечение работы оригинального ПО. Это было непросто, точных описаний ЭВМ не сохранилось, многие детали, особенно на стыках с телефонной аппаратурой, пришлось восстанавливать экспериментально. Когда новая ЭВМ, наконец, заработала на французских тестах, причем в 10 раз быстрее старой, оригинальное ПО не заработало.

Оказалось, что в оригинальном ПО оператор delay был реализован "жужжанием", т.е. задержка на 10 мсек реализовывалась повторением 100 раз команды со временем исполнения 100 микросекунд. А у нас эта же команда исполнялась всего 10 микросекунд! Пришлось выискивать все такие места и увеличивать число повторений в 10 раз.

Это к вопросу о том, почему я так не люблю дилетантов и троечников.