|
Общие принципы взаимодействия объектов в системе |
Система в целом состоит только из объектов. Под объектом при этом понимается сущность, которая имеет определенное состояние, обладает определенным поведением и обладает уникальной идентичностью. При этом:
Вся информация в системе на ЛЮБЫХ носителях представляется в виде объектов. Доступ к объектам в рамках системы обеспечивается только через методы объектов. Каждый объект имеет свой идентификатор, для работы с ID объектов в системе создается служба идентификации.
Все объекты принадлежат классам. Каждый класс имеет свой уникальный идентификатор, т.е. тоже является объектом. При этом в качестве свойств класса выступает описатель класса (неким аналогом в существующих системах может быть RTTI, возможно применение языка разметки на основе XML) и методы класса. Кроме того, каждый класс в системе имеет уникальное символьное имя. Для системных классов имя должно быть уникально в пределах глобального пространства имен задаваемого разработчиками системы, для прикладного ПО имя класса уникально в пределах одной ОС. Все объекты одного класса поддерживают одинаковый определенный при создании интерфейс (совокупность всех публичных методов доступа к объекту).
Объекты могут быть:
Все устойчивые объекты одного класса сохраняют свое состояние в соответствующем разделе ООБД, общей для всей системы. Для каждого устойчивого класса реализуется "фабрика класса" - внешний объект позволяющий создавать в ОП (загружать в ОП) объекты данного класса.
Устойчивые классы в обязательном порядке регистрируются в системе. Обязательными параметрами для регистрации являются:
Классы, из которых строится собственно система называются системными, они в обязательном порядке являются устойчивыми. Системный класс загружается в память в виде ОТДЕЛЬНОГО ПРОЦЕССА, т. е. получает в свое распоряжение отдельную "кучу" для выделения памяти под объекты этого класса и свое адресное пространство. Таким образом, обеспечивается доступ к данным системного класса только со стороны методов класса. Для системных классов "фабрика класса" размещается в том же процессе что и класс.
Устойчивые объекты могут создаваться в отдельном процессе аналогично с системными, либо встраиваться в пользовательские процессы, при этом данные устойчивого объекта располагаются в сегменте данных, а методы размещаются в сегменте кода пользовательского процесса, создавшего объект. В системе допускается возможность делать объект, созданный внутри приложения, и не являющийся устойчивым (временные объекты), доступным для внешних приложений (разделяемый объект). При этом класс объекта, который предполагается делать разделяемым, должен быть зарегистрирован в системе, процесс регистрации тот же, что и для устойчивого класса.
Поведение объектов реализуется посредством потоков процесса, в котором создан объект. Процесс и поток также являются объектом. Поток может реализовывать поведение единственного объекта или группы объектов.
Для организации взаимодействия между объектами зарегистрированных в системе классов, расположенными в разных процессах, предусматривается механизм IPC, который строится на передаче сообщений. Передача сообщения в общем случае является эквивалентом вызова метода объекта с одновременным применением средств синхронизации.
Для организации вызовов методов системного, устойчивого или разделяемого объекта из другого приложения создается его представитель (proxy) в функции которого входят маршалинг параметров вызова и возвращаемых результатов, с последующим вызовом функции ядра, осуществляющего создание нового сообщения в системе. Создание объекта-представителя производится посредством вызова методов системного объекта, реализующего функции диспетчера к "фабрикам классов", зарегистрированным в системе. При создании объекта-представителя диспетчер в общем случае вызывает объект системы контроля прав доступа, которым проверяются права процесса, запросившего создание объекта-представителя. В случае успешной проверки в процесс возвращается ненулевой указатель на созданный объект-представитель.
Вызов функции удаленного объекта оформляется как передача сообщения через IPC. Каждое сообщение IPC указывается ID отправителя, ID получателя сообщения, тип сообщения, указатель на буфер с данными сообщения, способ вызова сообщения, кроме того, может указываться приоритет для данного конкретного сообщения. Сообщения ставятся в приоритетную очередь на обработку. При постановке сообщения в очередь выполняется поиск процесса и потока, который представляет объект-получатель сообщения.
Предоставление процессорного времени потокам для обеспечения параллельной обработки сообщений производится специальным системным объектом - планировщиком потоков, на основании реализуемой им политики планирования. Для обеспечения вытесняющей многозадачности в системе планировщик потоков производит квантование процессорного времени, используя прерывание по таймеру. Величина кванта времени, выделяемого каждому конкретному потоку, является изменяемой в зависимости от состояния системы.
В планировщике потоков организуется связь сообщений с потоками их обрабатывающими. С каждым сообщением занесенным в очередь в общем случае может быть связан один или более потоков (например, для организации обработки широковещательных сообщений). Для обработки сообщения планировщик потоков производит активацию связанных с ним потоков. Политика планирования строится на основании приоритетов потоков. Приоритет потока зависит от обрабатываемого сообщения и действует в течение обработки конкретного сообщения. В случае если при отправке сообщения приоритет не указывался явно, поток получает приоритет по умолчанию, который был назначен при создании потока.
С точки зрения одновременной передачи нескольких сообщений одному и тому же объекту-получателю возможны 2 вида обработки сообщений:
В системе могут существовать потоки видов:
Потоки ядра предназначены для организации работы с ресурсами системы, которые разделяются всеми приложениями системы и, следовательно, допускают возможность блокировки от любого потока (в основном операции с устройствами ввода-вывода, ФС). Поток уровня ядра в системе может создаваться как реакция на приход в ядро сообщения адресованного ядру, или службе системы, для которого еще нет потока обработки (например, сообщение о принятии порции данных от обработчика прерываний), либо явно при выполнении системной функции создания потока.
Локальные потоки процессов организуются средой поддержки времени исполнения (runtime-средой).