Механизм удаленного доступа |
Как оговаривалось ранее, существует два различных механизма взаимодействия с удаленным объектом. Так как взаимодействуют два потока с непересекающимися адресными пространствами, то объекты определенные для работы внутри потоков владельцев, не могут вызывать методы друг-друга напрямую, поскольку абсолютные адреса используемые в коде методов настроены на смещение кода Offset m1 и Offset m2.
Рисунок 1
Как видно из рисунка – дальний вызов хоть и возможен, но может привести к непредсказуемости, в случае если код является позиционно зависимым.
Хорошо известно, что код объекта 1 и 2 совпадает, так как они являются объектами одного класса. Несовпадающими или уникальными являются только их данные. Таким образом, верно следующее, при работе кода объекта 1 с данными объекта 2 в алгоритме их обработки не произойдет изменений, как и в обратном случае. Более того - код одного из объектов является избыточным, а значит можно сформировать один из объектов, убрав из него код методов и перенаправив вызовы методов в полноценный объект, при этом заменив, ссылку на данные объекта ссылкой от объекта, инициировавшего вызов. В случае, рассмотренном выше объект инициирующий вызов методов называется объектом-«тенью», а объект к которому направлен вызов – удаленным объектом. Классифицируем запрос удаленного вызова, данного типа, как запрос методов удаленного объекта см рис.2.
Удаленный объект должен обладать рядом характерных конструктивных особенностей, для обеспечения удаленного доступа к нему. Класс такого объекта должен объявлять методы, к которым предоставляется удаленный доступ как виртуальные, по ряду причин:
Рисунок 2. Конструкция удаленного объекта.
Пункт 1, обеспечивается созданием специальных страниц ShаdowVMT не представленных в оперативной памяти, в которых происходит размещение таблицы VMT. Размещение указателей адресов методов класса, таблицы VMT в этой странице – фактически невозможно так реально ячейки памяти страницы (адреса) не представлены в ОЗУ. Эта особенность позволит контролировать доступ в страницу через страничное исключение процессора x86, где частично будет размещен и код модуля ядра «фабрика класса». Ситуация, в которой страничное исключение возникнет в результате обращения в страницу ShedowVMT на запись, будет расцениваться как несанкционированный доступ, с возможностью снятия потока допустившего данную ситуацию с исполнения. Ситуация, в которой происходит обращение в страницу ShedowVMT на чтение, расценивается как запрос методов удаленного объекта.
Пункт 2, обеспечивается компилятором, совместно с линкером, для создания исполнимого файла, в тело которого объект – «тень» попадет уже видоизмененным, без кода методов и практически без данных таблицы VMT. Конструкция объекта тени приведена на рис 3.
После того как «фабрика класса» перехватит вызов удаленного метода, будет произведен поиск по всем зарегистрированным объектом-«тень», для обнаружения кросс-таблиц методов для запрашиваемого объекта со стороны делающего запрос объекта-«тени». Для обеспечения уникальности каждого объекта созданного в системе, в конструкторе всех классов, происходит выделение уникального, глобального идентификатора объекта, вызвавшего конструктор. Обеспечить уникальность объекта можно, используя:
Рисунок 3. Конструкция объекта-«тени».
Кросс-таблица методов представляет из себя 2-мерный массив на каждый удаленный объект в ОС, одно измерение, которого - это уникальный идентификатор объекта-«тень», второе – это смещение (номер по порядку) указателя метода в таблице VMT объекта – «тень». На пересечении осей находится адрес метода в потоке, содержащем удаленный объект. Конструкция кросс-таблицы методов приведена на рис. 4.
Рисунок 4. Конструкция таблицы кросс-методов
Таблица кросс-методов заполняется заранее, до удаленного вызова метода, при регистрации объекта тени в «фабрике класса».
Поскольку работа методов может осуществляться только в адресном пространстве удаленного объекта, то при обработке поступившего запроса методов удаленного объекта, необходимо планировать работу потока содержащего удаленный объект и вызов метода. Для сокращения потерь от перепланировки потока при каждом вызове метода, можно производить вызовы методов в пакетном режиме, т.е. последовательно накопив запросы. Однако в таком случае последовательность вызовов (или единичный вызов) должна быть передана потоку, содержащему удаленный объект в виде адресов приведенных по отношению к границе сегмента кода потока владельца.
Приведением сегмента данных объекта-«тени» занимается «фабрика класса». Приведение сегмента осуществляется по приведенной на рис. 5 схеме к L1 приводятся L2 и L3.
Рисунок 5
Формула приведения границы сегмента:
Aп = Ai – (L1 – Li),
где
Приведенный сегмент размещается как селектор в LDT потока владельца УО, и размещается в поле DS TSS отправляемой на планирование потока владельца в диспетчере потоков, поле IP TSS заполняется адресом запрашиваемого метода, SS:SP заполняется значениями SS:SP во время вызова удаленного метода из запросившего удаленный доступ потока, все остальное это копия полей настоящей TSS для потока обслуживающего УО. При пакетном доступе дополнительно заполняются служебные поля TSS, как IP1,IP2,IP3…IPn, как адреса всех запрашиваемых методов и SS1:SP1….SSn:SPn стека для каждого помещенного в пакет метода. При этом длина TSS увеличивается, что отражается в поле типа TSS (как TSS удаленного пакетного доступа) и размера TSS.
Таким образом, реформируется очередь планирования потоков на S записей, определяющихся по формуле
S = N * Qi,
где