- •1. Общая х-ка систем реального времени
- •4._Архітектура ос qnx-6.
- •5. Основні компоненти ос рч та їх загальна характеристика (планувальник задач та диспетчер (ядро), обробники переривань, програма стеження за часом, адміністратор ресурсів).
- •6.Правила диспетчеризації потоків в сучасних ос рч (fifo,rr,тощо). Рівні пріоритетів. Механізми синхронізації.
- •8.Стани задач в ос рч
- •9.Планування та диспетчеризація задач в ос рч. Чинники та алгоритми планування.
- •10. Механізми взаємодії задач в ос рч (повідомлення, схеми обміну повідомленнями).
- •11. Концепция потоков и процессов
- •12. Методи синхронізації потоків.
- •13. Архітектура ос qnx-6.
- •14. Алгоритми планування задач в ос qnx-6
- •15. Дисципліни та правила диспетчеризації потоків в ос qnx-6.
- •16. Стани потоків в ос qnx-6
- •17. Запуск процесів та потоків в ос qnx-6.
- •18. Створення потоків в ос qnx-6
- •19. Копіювання процесів в ос qnx-6
- •20. Атрибути потоків в ос qnx-6.
- •21.Синхронизация потоков по мютексу.
- •22.Синхронизация потоков по семафору.
- •23.Синхронізація потоків за „приєднанням”. (взято из Кертона, изменяй, когда переписываешь)
- •24. Синхронізація потоків за «бар'єром».
- •25. Синхронізація операцій читання-запису.
- •26.Синхронізація потоків за ”чекаючим блокуванням”.
- •27.Алгоритм взаємодії потока-виробника та потока-приймача інформації на основі „чекаючих блокувань”.
- •28.Синхронізація потоків за „умовними змінними”.
- •29.Пули (pool) потоків та їх використання.
- •30. Алгоритм керування числом потоків в пулі потоків.
- •31. Обмін повідомленнями за моделлю "клієнт - сервер".
- •33. Обмін повідомленнями за моделлю "клієнт – сервер - субсервер". Смотри далее.
- •34. Обмін повідомленнями за моделлю "клієнт – сервер - субсервер".
- •35. Механізм обміну повідомленнями між клієнтом та сервером в ос qnx-6.
- •36. Визначення потрібного сервера та жетон клієнта.
- •37. Обмін повідомленнями великого розміру.
- •38. Складені повідомлення та механізм iov.
- •39. Повідомлення за типом “імпульс”. Передача та прийом імпульсу.
- •40. Механізм стеження за часом. Годинники та таймери.
- •41. Механізм стеження за часом. Схеми повідомлення про «тайм-аут».
- •42. Створення та використання таймерів в ос qnx-6.
- •43. Тайм-аути ядра ос qnx-6.
- •44. Обробка переривань в ос qnx-6.
- •45. Розподіл загальної пам'яті між процесами (розповісти про shm_open, mmap, shm_unlink).
- •46. Мікроядро Neutrino та його можливості.
- •47. Розробка консольних проектів срч в середовищі qnx-6.
- •48. Мікроядро Photon та його можливості.
- •49. Розробка проектів срч в середовищі Application Builder.
44. Обробка переривань в ос qnx-6.
Чтобы вызвать прерывание, аппаратура выставляет сигнал на линии прервания. Как только сигнал прерывания выставлен, ядро переключается на участок кода, который настраивает окружение для выполнения подпрограммы обработки прерывания – кода, который определяет, что должно происходить при обнаружении прервыания.
Обработчик прерываний обычно выполняет минимально возможный объем работы и завершается. Когда обработчик перываний завершается, он может либо сообщить ядру, что ничего больше не надо, либо что ядро должо выполнить некоторое действие, вследствие которого некий поток может переключиться в состояние READY.
Neutrino полностью обеспечивает управление аппаратными прерываниями. Для обработки прерываний приложения необходимо привязать нужную функцию обработки к искомому прерыванию, используя вызовы ядра. К одному аппаратному прерыванию могут быть привязаны несколько обработчиков, которые получают управления соотстветсвенно с приоритетом потоков, которым они принадлежать.
Время ожидания прерывания – время от момента появления аппаратного прерывания до выполенния первой команды программы обработки прерывания. Некоторые критические секции кода требуют, чтобы прерывания были временно заблокированы. Максимальное время блокировки прерывания обычно определяет время ожидания пререрывания в наихуджешм случае – у QNX это время составляет 0.5 – 2 мкс.
В некоторых случая, обработчик аппаратного прерывания с низким приоритетом должен ждать выполнение потока с более высоким приоритетом. Время ожидания диспетчеризации – это время между последней командой программы пользователя ы исполнением первой команды потока драйвера. Оно определеят время, которое необходимо, чтобы сохранить конеткст активного потока и восстановить контектс потока драйвера. Время ожидания диспетчеризации больше, чем время ожидания прерывания.
Фунции API для обработки прерываний основаны на системных запросах ядра:
InterruptAttach() – прикрепить функцию к вектору прерывания.
InterruptAttachEvent() – генерировать событие прерывания. Никакая программа обработки прерывания пользователя не выполняется.
InterruptDetach() – отделить функцию от прерывания, используя ID, InterruptAttach(), InterruptAttachEvent().
InterruptWait() – ожидать прерывание.
InterruptEnable() – включить аппаратные прерывания.
InterruptDisable() – отключить аппаратные прерывания.
InterruptMask() – маскировать аппаратное прерваение.
InterruptUnmask() – демаскировать аппаратное прерывание.
InerruptLock() – блокировать критическую секцию кода между программой обработки прерывания и потоком.
InterruptUnlock() - удалить блокирование на критической секции кода.
Используя этот набор API, поток уровня пользователя может вызывать InterruptAttach(), InterruptAttachEvent(). Можно многим обработчикам прерываний обрабатывать каждый номер аппаратного прерывания. Аппаратное устройство, которое сгенерировало прерывание, будет удерживать сигнал прерывания до тех пор, пока не удостоверится в том , что прерывание успешно обработано.
Псевдокод типичного прерывания:
Function ISR begin
Определяем источник прерывания
Очистить источник прерывания
If надо передать работу потоку then
Return(событие);
Else
Return(NULL);
Endif;
end
Событие, которое возвращается, должно быть описано вне ISR, чтобы оно существовало после возврата из ISR или может быть описано в ISR как статическое. При генерации события ядро перепланирует потоки. Если же ISR событие не возвращает, то перепланирование не произойдет и будет выполнятся поток, который был вытеснен ISR .