Redactor
Обмен сообщениями
В QNX Neutrino обмен сообщениями формирует виртуальную «программную» шину, которая позволяет производить апгрейды «на лету» — любой компонент в QNX Neutrino может быть добавлен или удален динамически. Использование этой технологии позволяет оставить в ядре операционной системы только основные сервисы, такие как сигналы, таймеры и планировщик.
Все другие компоненты – файловые системы, драйверы, стеки протоколов, приложения – выполняются в безопасном пространстве с защитой памяти. Реализуется встроенная устойчивость к сбоям. Кроме того, происходит прозрачное распределение сообщений между процессорами, обеспечивая непрерывный доступ к ресурсам в любой части сети.
Технология обмена сообщениями на основе микроядра позволяет:
автоматически синхронизировать выполнение взаимодействующих компонентов;
избавить вас от необходимости следить за очередностью доставки данных;
разбить сложное приложение на четко разграниченные функциональные блоки, которые можно разрабатывать и тестировать по отдельности;
придавать системам изящность, делающую их легкими в эксплуатации и обслуживании;
действовать по всей сети, предоставляя вашим приложениям прозрачный доступ к сервисам и ресурсам удаленных узлов.
Автоматическая синхронизация
Обмен сообщениями в QNX также чрезвычайно эффективен, поскольку каждая операция происходит непосредственно между отправителем и получателем. Соответственно, не происходит никакого промежуточного копирования данных и не требуется никаких дополнительных механизмов межзадачного взаимодейсвия для синхронизации.
Кроме того, нет необходимости реализовывать дополнительные уровни для обработки сложных сообщений. Чтобы обмениваться сообщениями с системными сервисами, приложения могут использовать стандартные вызовы POSIX.
Как это работает? В QNX Neutrino каждая программа, предоставляющая некий сервис (например, драйвер), может зарегистрировать в пространстве имен путей «файл» или «каталог». В дальнейшем любое приложение может соединиться с этим драйвером, осуществив по отношению к данному файлу или каталогу стандартную операцию open(). Результатом будет получение приложением обычного файлового дескриптора, через который приложение сможет обращаться к сервисам драйвера при помощи вызовов POSIX, предназначенных для работы с файловыми дескрипторами — read(), write(), lseek() и т.п. Библиотека языка Си автоматически преобразует эти вызовы в соответствующие сообщения и передает их драйверу. Например, когда приложение вызывает стандартную функцию read(), чтобы считать готовые данные, библиотека преобразует этот вызов в сообщение «запрос на чтение». На самом деле в QNX Neutrino приложения используют преимущества обмена сообщениями каждый раз, когда работают с файловыми дескрипторами или указателями на файлы.
Такой подход позволяет вам:
Упростить обслуживание систем — поскольку пространство имен путей четко отделяет сервисы от клиентских приложений, обновление для ваших систем становится элементарной задачей. Любой сервис можно заменить на его новую версию, в том числе в процессе эксплуатации — и клиенты сами автоматически найдут его.
Расширять ОС для нестандартных задач — QNX Neutrino предоставляет разработчикам библиотеку администратора ресурсов, которая позволяет сервисным программам регистрировать свои имена в пространстве имен путей и обрабатывать запросы от клиентских приложений.
В дополнение ко всему, в QNX Neutrino любые системные сервисы, включая драйверы, являются программами пользовательского кольца, а значит, разрабатываются точно так же, как и любые другие приложения. В результате вы получаете возможность легко расширять ОС совершенно новыми, специфичными для ваших приложений возможностями.
Обратите внимание, что обмен сообщениями можно использовать напрямую, при помощи функций MsgSend(), MsgReceive() и MsgReply(). В QNX Neutrino доступны также и традиционные формы межзадачного взаимодействия — программные каналы, FIFO, очереди сообщений POSIX, разделяемая память и сигналы.
