- •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.
36. Визначення потрібного сервера та жетон клієнта.
Архитектура клиент-сервер чаще всего предполагает, что клиент и сервер – это разные приложения, не имеющие никакой информации друг о друге. В QNX- 6 для организации обмена сообщениями сервер создает канал и блокируется в ожидании сообщения. Клиент в свою очередь, является инициатором обмена сообщениями. Для этого ему необходимо создать подключение с сервером, зная его nd|pid|chid(дескриптор узла, идентификатор процесса, идентификатор канала соответственно).
Самые распространенные способы для сервера сообщить, желающим подключиться клиентам, о своем местонахождении:
1. Открыть, известный клиенту, файл записать туда nd|pid|chid(самый распространенный в UNIX). Клиент читает из него все что надо. Этот подход относительно прост, но он имеет недостатки: загрязнение файловой системы, поскольку после сбоя в работе сервера файлы остаются, появляется необходимость в разработке механизмов удаления файлов при сбое сервера, необходимо разрабатывать механизмы обновления содержимого таких файлов.
2. Объявить nd|pid|chid как глобальные переменные, что допустимо для многопотоковых серверов, но не работает вне сервера.
3. Занять часть пространства имен и стать администратором ресурсов(является рекомендуемым общим решением). Сервер регистрирует некоторое имя пути как свою область ответственности, а клиенты обращаются к нему обычным вызовом функции open(имя_пути,...);
Создав подключение, клиент отправляет серверу сообщение MsgSend() и блокируется в ожидании ответа. Сервер в свою очередь, получив сообщение rcvid=MsgReceive(), разблокируется и начнет обработку полученного от клиента сообщения. После обработки сообщения сервер отвечает клиенту MsgReply(rcvid, ..), переводя его из состояния блокировки в состояние готовности. Переменной rcvid(идентификатор отправителя – целое число, его еще наз. жетон) осуществляется привязка приема сообщения от клиента к последующему ответу конкретному клиенту. В случае утери этого значения, и соответственно невозможности выполнить функцию MsgReply(), функция MsgSend() клиента не разблокируется, пока сервер работает или пока не настал тайм-аут соединения.
37. Обмін повідомленнями великого розміру.
По схеме:
Клиент отправляет сообщение MsgSend(); и блокируется. Сервер можетчитать данные из адресного пространства колиента MsgRead(…); или писать данные MsgWrite(…); А потом вызывает MsgReply() без данных для разблокировки. Ф-ции:
int MsgRead(int rcvid, void* msg, int nbytes, int offset);
rcvid – с кого читать
msg – куда читать в сервере
nbytes – количество байт
offset – смещение в клиентском буфере
При вызове сервер не блокируется, а клиент не разблокируется.
Возможный вариант схемы обмена:
1.Клиент создает большое сообщение с заголовком и посылает его серверу
2.Сервер принимает небольшую часть сообщения MsgReceive(…), а затем читает остальную часть с помощью MsgRead(…)
int MsgWrite(int rcvid, void* msg, int nbytes, int offset)
rcvid – откуда в сервере
msg – кому писать
nbytes – количество байт
offset – смещение в клиентском буфере
Сервер порциями передает данные, когда будет передана последняя порция данных, сервер делает вызов: MsgReply(rcvid, EOK, &header, sizeof(header)), чтобы «разбудить» клиента или MsgReply(rcvid, EOK, NULL, 0) указывая количество данных, которое он записал в клиентский буфер.