- •Устройство эвм
- •Процессорор
- •Микропрограммирование
- •Способы ускорения традиционных эвм
- •Нетрадиционные архитектуры эвм
- •//Архитектура бесперспективна, ибо запрограммировать задачу для такой машины по-видимому невозможно.
- •Матричные
- •Векторные
- •Конвейерные
- •Торовые (Grid)
- •История эвм
- •Традиционные архитектуры эвм на примере ibm/360
- •Risc, cisc – компьютеры
- •Основные принципы построения hll-машины «Самсон»
- •Организация памяти
- •Команды чтения-записи
- •Арифметические команды
- •Логические команды
- •Передача управления
- •Организация циклов
- •Работа с вырезками
- •Реализация виртуальной памяти
- •Реализация вызовов процедур
- •Сoroutine - сопрограмма
- •Парал. Процессы
- •Понятие технологии программирования
- •Жизненный цикл программы
- •Реализация
- •Постановка задачи, оценка осуществимости
- •Планирование
- •Управление
- •Проектирование, этапы проектирования
- •Вопрос 20(7). Технология Real. Статическая модель.
- •Конвертер из sdl в объектный программный код
- •Качество разработки по
- •Стандарт качества iso
- •Стандарт cmm
- •29. Организация коллектива разработчиков
- •30.Тестирование программ
- •31.Психология программирования
- •32.Документирование
- •33. Case-технологии
- •34.Сопровождение
- •35.Системы реального времени
- •36.Понятия сбоев и отказов
- •37.Инструментальная и целевая эвм
- •38.Комплекс вычислительных средств
- •39.Параллельные процессы, работа с временными интервалами
- •40.Организация вычислительных процессов
- •1.Процессы.
- •2. Данные.
- •41.Технология rtst
- •42.Технология real. Статическая модель
- •43.Технология real. Динамическая модель
40.Организация вычислительных процессов
Обычно считается, что используемая технология программирования должна обеспечить реализацию любой структуры, выдуманной проектировщиком. RTST - Real-Time Software Technology При разработке RTST мы заранее зафиксировали определенные структурные решения и тем самым ограничили разнообразие вариантов организации вычислительного процесса.
1.Процессы.
Параллельные процессы - классический способ описания поведения сложных систем - низкой эффективности реализации (свертка развертка процесса слишком долго) Чтобы эффективно использовать параллельные процессы, мы использовали особенность встроенных систем, состоящую в том, что обычно их процессы имеют очень короткие действия - переходы в терминах расширенной конечно-автоматной модели. Мы считаем, что если процесс получил управление по какому-то входному сигналу, то он должен довести переход до конца (до следующего состояния) и только затем передать управление диспетчеру, который определит, какой из процессов, готовых к исполнению (т.е. получивших сообщения), будет работать следующим.
Сообщений от других ЭВМ или оборудования - в непредсказуемые моменты времени. => Все функциональные процессы в один большой процесс ОС, внутри которого будем использовать синхронную организацию взаимодействия функциональных процессов, а драйверы сети, которые осуществляют буферизацию сообщений (никакой обработки!), будем реализовывать простыми обработчиками прерываний на стеке текущего процесса. Интересно заметить, что на 1 внешнее событие обычно приходится 5-10 внутренних переключений функциональных процессов.
Во-вторых, что будет, если один из процессов все-таки имеет слишком длинный переход? Тогда можно вставить несколько промежуточных фиктивных состояний (на практике это встречается крайне редко).
2. Данные.
Традиционным подходом к разработке ПО встроенных систем является построение единой базы данных (централизованной или распределенной), к которой все процессы обращаются через специальные примитивы доступа. – неэффективно и опасно - перед тем как писать или читать данные, надо их монополизировать.
Объектно-ориентированный подход(Во-первых, не вызовет ли разбиение данных на сравнительно мелкие объекты (с точностью до прибора)): объекты состоят из команд и данных. Внутри себя объект строго последователен. Если нужны данные другого объекта, можно послать ему сообщение. Тот вернёт соответствующее значение. У каждого объекта есть очередь входных сообщений. Каждое сообщение обрабатывается отдельно. Не возникает проблем с одновременным чтением/записью.
Посылка сообщения не менее, а может быть и более дорогое действие, чем свёртка/развёртка процесса. Это приводит к толкотне процессов.
Можно придумать распределение задач по объектам в конвейерном стиле.
Сначала управление получает один объект, который, пользуясь своими локальными данными, выполняет определенные действия и посылает сообщение следующему объекту с результатами своей работы в качестве параметра сообщения, т.е. сообщения играют не только информационную, но и управляющую роль.
(АЛ – Абонентская Линия; СЛ – Соединительная Линия; ТК – Телефонная Книга; КП – Коммутационное Поле.)
программ, вызываемых по прерываниям.
Когда абонент поднимает трубку, соответствующий объект АЛ получает сообщение, принимает все цифры номера и посылает сообщение объекту ТК с принятым номером в качестве параметра. Заметим, что все это время АЛ работает только со своими локальными данными. ТК осуществляет поиск вызываемого абонента также только по своим локальным данным и посылает сообщение найденному объекту типа АЛ или СЛ. Вызываемый абонент или соединительная линия по своим локальным данным определяет, занят он или свободен, и если свободен, то посылает сообщение КП на подключение. КП по своим локальным данным находит свободную промлинию и т.д.