Модифицированная компьютерная архитектура с согласованными объектами

009926 Область техники Настоящее изобретение относится к компьютерной технике, а более конкретно к модифицированной машинной архитектуре, обеспечивающей выполнение программы приложения одновременно на нескольких компьютерах, соединенных друг с другом сетью связи. Уровень техники Первоначально, с момента появления компьютеров и вычислительной техники, программное обеспечение для компьютеров предназначалось для работы на одиночной машине. На фиг. 1 показана такая известная из уровня техники одиночная машина 1, которая содержит центральный процессор 2 (ЦП),подсоединенный к запоминающему устройству 3 через шину 4. Также к шине 4 подсоединены различные функциональные блоки этой одиночной машины 1, такие как монитор 5, клавиатура 6 и мышь 7. Производительность машины 1 значительно ограничена тем обстоятельством, что данные должны быть обработаны в ЦП 2, а результаты этих операций должны быть переданы по шине 4. Шина 4 испытывает целый ряд проблем, включая так называемые "очереди" на шине (создаваемые узлами, которые стремятся получить доступ к шине), проблемы конфликтов и т.п. Эти проблемы, до определенной степени, могут быть решены с помощью различных обходных путей, включающих использование кэшпамяти, однако все эти пути неизменно увеличивают для машины 1 затраты на управление. Естественно, в течение всех лет компьютерной эры предпринимались различные попытки увеличить производительность машин. Один из таких подходов состоит в использовании множества симметричных процессоров. Этот подход на существующем уровне техники используется в так называемых суперкомпьютерах и схематически проиллюстрирован на фиг. 2. Здесь множество процессоров 12 подсоединено к глобальной памяти 13. Однако в каналах связи между процессорами 12 и памятью 13 опять возникают "узкие места". Этот процесс получил название "единый образ системы". Существует только одно приложение и одна полная копия памяти для этого приложения, которая распределена в глобальной памяти. Это одиночное приложение может считывать информацию и записывать ее (т.е. совместно использовать) в любой ячейке памяти совершенно прозрачным образом. При наличии нескольких таких машин, взаимодействующих через сеть, указанный подход обеспечивается путем использования единственного приложения, написанного для одиночной машины, и разделения требуемых ресурсов памяти на части. Эти части далее распределяются между множеством компьютеров для создания глобальной памяти 13, доступной всем ЦП 12. Такая процедура основывается на маскировании (или сокрытии) разбиения памяти от единственной работающей прикладной программы. Производительность падает, когда один ЦП на одной машине вынужден обращаться (через сеть) по адресу памяти, физически находящемуся на другой машине. Хотя суперкомпьютеры оказались технически успешными с точки зрения высокой скорости вычислений, они не имеют коммерческого успеха по причине присущей им сложности, которая делает необычайно дорогим не только их производство, но и управление ими. В частности, концепция единого образа системы так и не смогла выйти на рынок "товарных" (или массово используемых) компьютеров и сетей. В частности, концепция единого образа системы нашла практическое применение только в сверхбыстрых (а, следовательно, сверхдорогих) компьютерах, объединенных в сверхбыстрые (и такие же дорогие) сети. Другая известная из уровня техники возможность увеличения мощности компьютеров путем использования нескольких машин обусловлена концепцией распределенных вычислений, схематически проиллюстрированной на фиг. 3. Эта известная система предполагает, что одно приложение (Ар) разделено автором (или другим программистом, который ознакомился с приложением) на несколько отдельных задач, для выполнения, скажем, на трех машинах; в этом случае "n" на фиг. 3 - это целое число 3. Намерение здесь таково, что на каждой из машин M1 М 3 выполняется соответствующая треть всего приложения и что нагрузка на разные машины примерно одинакова. Машины взаимодействуют через сеть 14, которая может быть представлена различными формами, например, канал связи, Интернет, Интранет, локальная сеть и т.д. Обычно скорость выполнения операций в таких сетях 14 на порядок меньше скорости выполнения операций шины 4 на каждой из отдельных машин M1, M2 и т.д. Распределенные вычисления имеют целый ряд недостатков. Во-первых, разделить приложение трудно и делать это нужно вручную. Во-вторых, передача по сети 14 данных, промежуточных результатов, результатов и т.п. обуславливает административные расходы. В-третьих, факт разделения чрезвычайно затрудняет расширение системы на большее число машин, поскольку приложение, разделенное,например, на три части, плохо выполняется на четырех машинах. В-четвертых, если одна из машин выходит из строя, то общая производительность всей системы значительно падает. Следующая известная из уровня техники система основана на сетевых "кластерных" вычислениях. Она схематически проиллюстрирована на фиг. 4. Согласно данному подходу приложение целиком загружают на каждую из машин M1, M2, , Mn. Каждая машина взаимодействует с общей базой данных,однако не взаимодействует напрямую с другими машинами. Хотя на каждой машине запущено одно и то же приложение, каждая из машин выполняет свое "задание" и использует только свою собственную память. Это немного похоже на ряд кассовых окошек, в каждом из которых продаются железнодорожные билеты пассажирам. Этот подход действительно работает и является расширяемым. Но он имеет недос-1 009926 таток, заключающийся в сложности администрирования такой сети. В таких компьютерных языках, как JAVA и MICROSOFT.NET, программисты имеют дело с двумя основными типами конструкций. В языке JAVA эти конструкции известны как объекты и классы. Каждый раз при создании объекта запускается подпрограмма инициализации, известная как "init". Аналогично, каждый раз при загрузке класса запускается подпрограмма инициализации, известная как"clinit". В других языках используют иные термины, однако принцип остается тем же. Однако нет эквивалентной подпрограммы "очистки" или удаления объекта или класса, когда они больше не нужны. Вместо этого "очистка" выполняется незаметно в фоновом режиме. Кроме того, в любой вычислительной среде необходимо получать и снимать блокировку для разрешения использования конфигураций, ресурсов или структур, чтобы предотвратить ситуации, когда различные части приложения пытаются использовать одни и те же ресурсы одновременно. В среде JAVA это известно под названием "синхронизация". Она достигается в JAVA с помощью команд или подпрограмм "monitor enter" и "monitor exit". В других языках используют иные термины, однако принцип остается тем же. В настоящем изобретении представлена компьютерная среда, в которой приложение работает одновременно на множестве компьютеров. В подобной среде необходимо обеспечить, чтобы вышеупомянутые процедуры инициализации, очистки и синхронизации выполнялись согласованно и скоординированно на всех машинах. Именно эта задача координации является целью настоящего изобретения. В соответствии с первым аспектом настоящего изобретения предложена многокомпьютерная система, имеющая по меньшей мере одно приложение, запущенное одновременно на множестве объединенных сетью связи компьютеров, в которой создано однородное множество идентичных, по существу, объектов, каждый из которых создается на соответствующем компьютере и имеет идентичное, по существу,имя, причем начальное содержание каждого из указанных идентично названных объектов, по существу,одинаково, при этом все указанные идентичные объекты одновременно удаляются, если каждый из указанного множества компьютеров более не нуждается в обращении к своим соответствующим объектам; также данная система содержит средство блокировки, применимое ко всем указанным компьютерам, при этом любой компьютер, намеревающийся использовать некий поименованный объект на нем, получает авторизационный блокиратор из указанного средства блокировки, который разрешает ему это использование и который предотвращает использование всеми другими компьютерами их соответствующих поименованных объектов до тех пор, пока указанный блокиратор не будет снят. В соответствии со вторым аспектом настоящего изобретения предложен способ выполнения по меньшей мере одного приложения одновременно на множестве компьютеров, которые соединены друг с другом сетью связи, содержащий следующие шаги:(i) создание однородного множества идентичных, по существу, объектов, каждый на соответствующем компьютере и каждый с идентичным, по существу, именем,(ii) создание идентичного, по существу, начального содержания каждого из указанных идентично поименованных объектов,(iii) одновременное удаление всех указанных идентичных объектов, если все из указанного множества компьютеров более не нуждаются в обращении к своим соответствующим объектам,(iv) предписание каждому из указанных компьютеров, намеревающемуся использовать некий поименованный на нем объект, получать авторизационный блокиратор, который разрешает ему это использование и который предотвращает использование всеми другими компьютерами их соответствующих поименованных объектов до тех пор, пока указанный блокиратор не будет снят. В соответствии с третьим аспектом настоящего изобретения предложен компьютерный программный продукт, содержащий набор команд. Этот продукт находится на носителе информации и может быть запущен на выполнение для реализации на множестве компьютеров вышеуказанного способа. Краткое описание рисунков Далее со ссылкой на приложенные рисунки описаны варианты выполнения данного изобретения,при этом: фиг. 1 схематически изображает внутреннюю архитектуру обычного компьютера,фиг. 2 схематически изображает внутреннюю архитектуру известной симметричной многопроцессорной системы,фиг. 3 схематически иллюстрирует известный из уровня техники способ распределенных вычислений,фиг. 4 схематически иллюстрирует известный из уровня техники способ сетевых кластерных вычислений,фиг. 5 схематически изображает структурную схему множества машин, на которых запущено одно и то же приложение, в соответствии с первым вариантом настоящего изобретения,фиг. 6 схематически изображает известный из уровня техники компьютер, выполненный с возможностью работы с JAVA-кодом и, таким образом, представляющий собой виртуальную JAVA-машину,фиг. 7 - иллюстрация, сходная с фиг. 6, но показывающая начальную загрузку кода в соответствии с предпочтительным вариантом изобретения,-2 009926 фиг. 8 - иллюстрация, сходная с фиг. 5, но показывающая соединение друг с другом множества компьютеров, каждый из которых работает с JAVA-кодом таким же образом, как показано на фиг. 7,фиг. 9 изображает блок-схему процедуры, согласно которой одно и то же приложение загружается на каждую машину в сети,фиг. 10 изображает блок-схему, показывающую измененную процедуру, схожую с той, что показана на фиг. 9,фиг. 11 схематически иллюстрирует многопоточную обработку, выполняемую показанными на фиг. 8 машинами с использованием первого варианта обновления памяти,фиг. 12 - схематическое представление, сходное с фиг. 11, однако иллюстрирующее альтернативный вариант,фиг. 13 представляет многопоточное обновление памяти компьютеров, показанных на фиг. 8,фиг. 14 схематически изображает известный из уровня техники компьютер, предназначенный для работы с JAVA-кодом и, таким образом, представляющий собой виртуальную JAVA-машину,фиг. 15 схематически изображает "n" машин, на которых запущено приложение и которые обслуживаются дополнительной серверной машиной X,фиг. 16 изображает блок-схему модифицированных подпрограмм инициализации,фиг. 17 изображает блок-схему, иллюстрирующую продолжение или прекращение работы подпрограмм инициализации,фиг. 18 изображает блок-схему, иллюстрирующую запрос, отсылаемый на серверную машину X,фиг. 19 изображает блок-схему ответа серверной машины X на запрос, показанный на фиг. 18,фиг. 20 изображает блок-схему модифицированной подпрограммы инициализации для командыclinit,фиг. 21 изображает блок-схему модифицированной подпрограммы инициализации для командыinit,фиг. 22 изображает блок-схему модифицированных подпрограмм "clean up" или финализации,фиг. 23 изображает блок-схему, иллюстрирующую продолжение или прекращение подпрограмм финализации,фиг. 24 изображает блок-схему, иллюстрирующую запрос, отсылаемый на серверную машину X,фиг. 25 изображает блок-схему ответа серверной машины X на запрос, показанный на фиг. 24,фиг. 26 изображает блок-схему модифицированных подпрограмм "monitor enter" и "exit",фиг. 27 изображает блок-схему процесса, в соответствии с которым машина запрашивает получение блокиратора,фиг. 28 изображает блок-схему, иллюстрирующую запрос на снятие блокиратора,фиг. 29 изображает блок-схему ответа серверной машины X на запрос, показанный на фиг. 27,фиг. 30 изображает блок-схему, иллюстрирующую ответ серверной машины X на запрос, показанный на фиг. 28,фиг. 31 схематически изображает два портативных компьютера, соединенные для одновременного запуска группы приложений, причем оба приложения запущены на одном компьютере,фиг. 32 - изображение, сходное с фиг. 31, однако показывающее систему, представленную на фиг. 31, в которой на каждом компьютере запущено по одному приложению, и фиг. 33 - изображение, сходное с фиг. 31 и 32, однако показывающее систему, представленную на фиг. 31, в которой оба приложения одновременно запущены на обоих компьютерах. Данное описание включает приложения А, В, С и D, в которых представлены фрагменты действительного программного кода, воплощающие различные аспекты описанных вариантов. Приложение А относится к полям, а приложение В относится к инициализации. Приложение С относится к финализации. Приложение D относится к синхронизации. Подробное описание Согласно фиг. 5, иллюстрирующей предпочтительный вариант изобретения, одиночное приложение 50 может быть запущено одновременно на нескольких машинах M1, M2, , Mn, взаимодействующих по сети 53. Как станет ясно из нижеследующего, на каждой из машин M1, M2, , Mn запущено одно и то же приложение 50, и, таким образом, все машины M1, M2, , Mn имеют программный код и данные одного и того же приложения 50. Аналогично каждая из машин M1, M2, , Mn работает с одним и тем же (или по существу одним и тем же) модификатором 51, установленным на каждой из машин M1, M2, , Mn. То есть все машины M1, M2, , Mn имеют один и тот же (или по существу один и тот же) модификатор 51,причем модификатор машины М 2 обозначен как 51/2. Кроме того, во время загрузки (или до выполнения) приложения 50 на каждой из машин M1, M2, , Mn, каждое приложение 50 модифицируется соответствующим модификатором 51 по одним и тем же правилам (или по существу по одним и тем же правилам, поскольку допустимы незначительные оптимизационные изменения в каждом из модификаторов 51/151/n). Из вышеописанного следует, что если каждая из машин M1, M2, , Mn имеет ресурсы совместно используемой памяти, допустим 10 Мб, то объем общей совместно используемой памяти, доступной каждому из приложений 50, не 10n Мб, как можно было бы ожидать, а лишь 10 Мб. Однако далее поясня-3 009926 ется как это сказывается на улучшении работы. Естественно, каждая машина M1, M2, , Mn имеет ресурс нераспределенной памяти. Ресурсы нераспределенной памяти машин M1, M2, , Mn, как правило,приблизительно одинаковые, но это не является обязательным условием. Из уровня техники известно управление машиной (произведенной каким-либо производителем и имеющей операционную систему, написанную на каком-либо языке) посредством какого-либо языка приложения с помощью создания виртуальной машины, как схематически показано на фиг. 6. Известная из уровня техники система, показанная на фиг. 6, имеет форму приложения 50, написанного на языкеJAVA и исполняемого в рамках виртуальной JAVA-машины 61. Таким образом, если предполагаемый язык приложения - JAVA, то создается виртуальная JAVA-машина, которая способна работать с JAVAкодом вне зависимости от производителя машины и ее внутренних особенностей. Более подробно об этом можно узнать в работе "The JAVA Virtual Machine Specification", 2-е издание, LindholmF. Yellinof Sun Microsystems Inc. США. Согласно предпочтительному варианту данного изобретения в эту хорошо известную показанную на фиг. 6 систему внесены изменения, более конкретно - введено дополнительное средство, получившее название "распределенное исполнение программы" 71 или DRT ("distributed run time"), как показано на фиг. 7. Согласно фиг. 7 приложение 50 загружается на виртуальную JAVA-машину 72 через средство 71 распределенного исполнения программы в ходе процедуры загрузки, показанной стрелкой 75. Средство распределенного исполнения программы можно получить в Фонде Открытого Программного Обеспечения (Open Software Foundation) под названием Среда Распределенных Вычислений (Distributed ComputingEnvironment, DCE). В частности, средство 71 распределенного исполнения программы приводится в действие во время процедуры загрузки JAVA-приложения 50, обозначенной стрелкой 75, чтобы первоначально создать виртуальную JAVA-машину 72. Последовательность операций, происходящих при загрузке, описана далее со ссылкой фиг. 9. На фиг. 8 показана в модифицированной форме система с фиг. 5, использующая виртуальныеJAVA-машины, показанные на фиг. 7. Ясно, что на каждую из машин M1, М 2, , Mn загружается опять одно и то же приложение 50. Хотя взаимодействие между машинами M1, M2, , Mn, показанное стрелками 83, физически маршрутизируется аппаратными средствами машины, управление этим взаимодействием осуществляют индивидуальные средства DRT 71/171/n в каждой машине. Таким образом, на практике это можно концептуально выразить так: по сети 73 взаимодействуют скорее средства DRT 71/171/n, нежели сами машины M1, M2, , Mn. Обратимся теперь к фиг. 7 и 9. Во время процедуры 75 загрузки происходит модификация программы 50, загружаемой для создания виртуальной JAVA-машины 72. Эта модификация начинается на шаге 90 (фиг. 9) и включает в себя начальный шаг 91 определения всех адресов памяти (называемых "полями" в JAVA, однако в других языках употребляются эквивалентные термины) в загружаемом приложении 50. Такие адреса памяти необходимо идентифицировать для последующей обработки на. шагах 92 и 93. Средство DRT 71 во время процедуры 75 загрузки создает список всех идентифицированных таким образом адресов памяти, поля JAVA включены в список как объект и класс. В список включены как подвижные, так и синхронные поля. На следующей фазе процедуры модификации (92 на фиг. 9) происходит поиск в коде исполняемого приложения для обнаружения любого вычислительного процесса, который регулирует или изменяет значения полей из созданного на шаге 91 списка и, таким образом, осуществляет запись в поля, так что значение по соответствующему адресу памяти изменяется. Когда подобная операция (обычно на языкеJAVA это "putstatic" или "putfield"), изменяющая значение поля, обнаружена, то в данном месте программы происходит вставка на шаге 93 "подпрограммы распространения обновлений", чтобы тем самым известить все другие машины об изменении значения данного поля. Далее, процедура загрузки продолжается в нормальном режиме, что показано шагом 94 на фиг. 9. Альтернативная форма начальной модификации во время загрузки изображена на фиг. 10. Здесь шаги "запуск" 90 и "создание списка" 91, а также шаг 92 поиска идентичны аналогичным шагам на фиг. 9. Однако вместо вставки "подпрограммы распространения обновлений", как на шаге 93, в которой вычислительный поток производит обновление, происходит вставка "подпрограммы предупреждения" на шаге 103. "Подпрограмма предупреждения" дает команду потоку или потокам, не занятым в вычислениях и назначенным для DRT, выполнить необходимое распространение. Данный шаг 103 - более быстрая альтернативная процедура, снижающая временные издержки. После того как во время процедуры загрузки состоялась данная начальная модификация, осуществляется любая из многопоточных операций обработки, показанных на фиг. 11 и 12. На фиг. 11 показано как происходит многопоточная обработка 110 на машинах, состоящая из потоков 111/1111/4, причем обработка второго потока (в данном случае 111/2) заканчивается тем, что поток 111/2 на шаге 113 получает данные об изменении значения поля. На данном этапе нормальная обработка этого потока 111/2 останавливается на шаге 114, и тот же самый поток 111/2 передает по сети 53 всем другим машинам М 2Mn идентификатор измененного поля и измененное значение, изменение которого произошло на шаге 113. В конце этой процедуры взаимодействия поток 111/2 возобновляет обработку на шаге 115 до следующего экземпляра класса, где имеет место изменение значения поля.-4 009926 Согласно альтернативной схеме, показанной на фиг. 12, как только поток 121/2 получает данные об изменении значения поля на шаге 113, он извещает DRT-обработку 120 (как показано на шаге 125 стрелкой 127) о том, что еще по меньшей мере один поток 121/1, назначенный для DRT-обработки 120, должен распространить, в соответствии с шагом 128, по сети 53 на все другие машины М 2Mn идентификатор измененного поля и измененное значение, обнаруженное на шаге 113. Данная операция может быть проведена быстро и, таким образом, обработка начального потока 111/2 прерывается лишь на мгновение,как показано на шаге 125, перед тем, как поток 111/2 возобновляет обработку на шаге 115. Другой поток 121/1, который был извещен об изменении (как показано стрелкой 127), далее пересылает данные об этом изменении, как показано на шаге 128, через сеть 53 на каждую из других машин М 2Mn. Эта вторая схема на фиг. 12 повышает эффективность использования вычислительных мощностей различных потоков 111/1111/3 и 121/1 (которые, в общем случае, обслуживают неравные запросы) и дает улучшенную масштабируемость с увеличением числа "n" (здесь n - целое число, равное или большее 2, представляющее общее число машин, которые объединены сетью 53 и на которых одновременно запущено приложение 50). Вне зависимости от того, какая схема используется, измененное поле и идентификаторы, а также значения, обнаруженные на шаге 113, распространяются на все другие машины М 2Mn в сети. Это показано на фиг. 13, где средство DRT 71/1 и его поток 121/1 на фиг. 12 (представлен шагом 128 на фиг. 13) передает по сети 53 идентификатор и измененное значение адреса памяти из списка, возникшие на шаге 113 (фиг. 12) при обработке на машине M1, на каждую из других машин М 2Mn. Каждая из других машин М 2Mn выполняет действие, обозначенное шагами 135 и 136 на фиг. 13 для машины Mn, путем получения пары "идентификатор - значение" по сети 53 и записи нового значения по соответствующему локальному адресу памяти. Согласно схеме, известной из уровня техники, в которой используется распределенное программное обеспечение (фиг. 3), обращения программного обеспечения одной машины к памяти, физически расположенной на другой машине, разрешается сетью, связывающей эти машины. Однако такие обращения к памяти могут иметь своим следствием задержки вычислений порядка 106-107 циклов ЦП данной машины. Это обстоятельство в большой степени ответственно за снижение производительности в сети,объединяющей множество машин. Однако понятно, что согласно настоящей схеме, описанной выше со ссылкой на фиг. 8, все процессы чтения данных производятся локально, так как текущее значение всех полей сохранено на машине,выполняющей обработку, которая создает запрос на считывание памяти. Такая локальная обработка может быть выполнена в течение 102-103 циклов ЦП. Таким образом, на практике, по существу, отсутствуют задержки при обращениях к памяти, которые требуют процессов считывания. Однако, как правило, прикладные программы считывают из памяти часто, а записывают в нее относительно редко. Как следствие, интенсивность, с которой в памяти записываются и перезаписываются данные, относительно невелика по сравнению с интенсивностью, с которой данные из памяти считываются. Таким образом, по причине небольшого числа запросов на запись и перезапись памяти, поля могут постоянно обновляться с относительно невысокой скоростью через недорогую обычную сеть 53, поскольку этой невысокой скорости достаточно для удовлетворения запросов прикладных программ на запись в память. В результате производительность схемы на фиг. 8 намного превышает производительность схемы на фиг. 3. Согласно дополнительной модификации изобретения идентификаторы и значения измененных полей могут быть объединены в пакеты, чтобы еще более снизить требования к скорости взаимодействия в сети 53, соединяющей различные машины. Специалистам данной области техники понятно, что в таблице, созданной каждым средством DRT 71 во время первоначальной записи полей, для каждого поля существует имя или идентификатор, являющийся общим для всей сети и опознаваемый всей сетью. Однако в каждой отдельной машине адрес памяти, соответствующий определенному поименованному полю, будет изменяться с течением времени,так как каждая машина будет последовательно сохранять измененные значения полей по различным адресам в соответствии со своими внутренними процессами. Таким образом, таблица в каждом средствеDRT будет иметь различающиеся адреса памяти, однако каждое глобальное "имя поля" будет иметь одно и то же "значение поля", записанное по различным адресам памяти. Специалистам данной области техники также понятно, что вышеупомянутая модификация приложения во время загрузки может быть достигнута пятью способами, а именно:(i) рекомпиляция во время загрузки,(ii) процедура прекомпиляции перед загрузкой,(iii) компиляция перед загрузкой,(iv) динамическая компиляция,(v) рекомпиляция после загрузки (или, например, до выполнения релевантного или соответствующего программного кода приложения в распределенной среде). Традиционно термин "компиляция" обозначает изменение в коде или языке, например, изменение от источника к объектному коду, или от одного языка к другому. Однако следует понимать, что в данном-5 009926 изобретении термин "компиляция" (и его грамматические эквиваленты) не является ограниченным, и может также включать в себя или охватывать модификации в пределах одного и того же кода или языка. Согласно первому варианту изобретения отдельная машина, скажем, машина М 2, загружает в себя код приложения, модифицирует его и затем загружает модифицированный код на каждую из машин M1,M3, , Mn (последовательно или одновременно). Согласно данной схеме, которую можно назвать "ведущий/ведомый" ("master/slave"), каждая из машин M1, М 3, , Mn загружает то, что ей выдает машина М 2. Согласно другому варианту изобретения каждая машина получает код приложения, но модифицирует его и загружает в себя модифицированный код. Это позволяет производить модификацию на каждой из машин немного иначе, оптимизируя ее на базе архитектуры и операционной системы данной машины, и все же эта модификация соответствует всем остальным подобным модификациям. Согласно еще одной схеме, отдельная машина, скажем M1, загружает немодифицированный код, а все остальные машины М 2, М 3, , Mn производят модификацию, чтобы удалить первоначальный код приложения и загрузить модифицированную версию. В любом случае передача данных может быть или "ветвеобразной" (т.е. М 2 передает данные на каждую из машин M1, М 3, М 4 и т.д. напрямую), или "каскадной", или "последовательной" (т.е. М 2 передает M1, которая затем передает М 3, которая затем передает М 4, и т.д.). Согласно еще одной схеме, машины M1-Mn могут передавать все запросы на загрузку дополнительной машине (не показана), на которой не запущено данное приложение, которая выполняет модификацию посредством любого вышеизложенного метода и возвращает модифицированную подпрограмму на каждую из машин M1-Mn, которые затем загружают модифицированную подпрограмму локально. По данной схеме машины M1-Mn направляют все запросы на загрузку на данную дополнительную машину,которая возвращает модифицированную подпрограмму на каждую из этих машин. Объем правовой охраны данного изобретения распространяется на любые модификации, выполняемые этой дополнительной машиной. Специалисты в области компьютерных технологий знают, что существуют по меньшей мере четыре технологии внесения модификаций в компьютерный код. Первая состоит в том, чтобы вносить модификации в исходный язык (язык-источник). Вторая заключается в том, чтобы конвертировать исходный код(скажем, JAVA) в промежуточное представление (или промежуточный язык). После проведения такой конвертации проводится указанная модификация, а потом - обратная конвертация. Желаемым результатом этого является модифицированный JAVA-код. Третья возможность - конвертация в машинный код (напрямую или через упомянутый промежуточный язык). Далее машинный код модифицируется перед загрузкой и исполнением. Четвертая возможность заключается в конвертации исходного кода в промежуточное представление, которое затем модифицируется и далее конвертируется в машинный код. Настоящее изобретение охватывает все четыре пути модификации, а также комбинацию двух, трех или даже всех четырех этих путей. Далее обратимся к фиг. 14, на которой схематически представлен известный из уровня техники компьютер, работающий как виртуальная JAVA-машина. Здесь машина (произведенная каким-либо производителем и имеющая операционную систему, работающую на каком-либо языке) может выполнять приложение 50 на конкретном языке, в данном примере на языке JAVA. Таким образом, виртуальнаяJAVA-машина 72 способна работать с кодом 50 на языке JAVA и использовать JAVA-архитектуру вне зависимости от производителя машины и ее внутреннего устройства. На языке JAVA подпрограмма инициализации clinit отрабатывает только один раз, когда загружается файл 50 А данного класса. Однако подпрограмма инициализации init работает часто, например,каждый раз, когда создается новый объект 50X, 50Y и 50Z. К тому же классы загружаются ранее объектов, так что в приложении, показанном на фиг. 14 и имеющем только один класс 50 А и три объекта 50X50Z, первый класс 50 А загружается в первую очередь, затем загружается первый объект 50 Х, затем второй объект 50Y и наконец загружается третий объект 50Z. Если, как на фиг. 14, имеется только одиночный компьютер или машина 72, то при выполнении подпрограмм инициализации, которые должны выполняться во время процедуры загрузки, не возникнет конфликтов или противоречий. Однако на схеме, показанной на фиг. 8 (а также на фиг. 31-33), имеется множество отдельных компьютеров или машин M1, M2, , Mn, соединенных сетью 53 связи, для каждого из которых предусмотрен модификатор 51 и на каждый из которых загружено общее приложение 50. По существу, модификатор 51 должен воспроизвести идентичную структуру и содержание памяти на каждой из отдельных машин M1, М 2, , Mn. Из этого следует, что в такой компьютерной среде необходимо удостовериться, что все отдельные машины инициализированы непротиворечивым образом. Модифицирующую функцию показанного на фиг. 5 модификатора 51 обеспечивает средство DRT 71, показанное на фиг. 8. Чтобы обеспечить согласованную инициализацию, приложение 50 подвергают тщательной проверке для выявления тех шагов программы, которые определяют подпрограмму инициализации. Данная поверка может иметь место или до загрузки, или во время процедуры 75 загрузки, или даже после процедуры 75 загрузки (однако до выполнения соответствующего релевантного кода приложения). Это можно-6 009926 сравнить с процедурой компиляции, понимая, что термин "компиляция" обычно подразумевает изменение кода или языка, например, из исходника в объектный код или из одного языка в другой. Однако в настоящем примере термин "компиляция" (и его грамматические эквиваленты) не является ограниченным и распространяется на модификации в рамках самого кода или языка кода (обычно несколько команд) с созданием модифицированной подпрограммы clinit. Эта модифицированная подпрограмма нужна для загрузки класса 50 А на одну из машин, например, JVM1, и для извещения всех других машин М 2Mn о том, что такой класс 50 А существует, и о его нынешнем состоянии. Данная модификация и загрузка могут быть выполнены в нескольких различных режимах. Так, в одном из режимов средство DRT 71, производящее загрузку машины, в данном случаеJVM1, запрашивает DRT 71/271/n всех других машин, инициализирован ли уже первый класс 50 А. Если ответ на это вопрос "да", то нормальная процедура инициализации выключается или запрещается. Если же ответ "нет", то проводится нормальная процедура инициализации и последующие изменения,проводимые во время этой процедуры, передаются всем остальным машинам, что обозначено стрелкой 83 на фиг. 8. Схожая процедура происходит каждый раз при загрузке объекта, скажем, 50 Х, 50Y или 50Z. ЕслиDRT 71/1 не определяет в результате опроса, загружен или нет конкретный объект, скажем объект 50Y,на другие машины М 2Mn, то DRT 71/1 запускает процедуру инициализации объекта и загружает на каждую из других машин М 2Mn эквивалентный объект (к которому удобно применить термин "равноправный объект") вместе с копией первоначальных значений. Однако, если DRT 71/1 определяет, что объект 50Y, о котором идет речь, уже существует на других машинах, то происходит запрет нормальной функции инициализации и создается локальная копия вместе с копией текущих значений. Желаемый результат опять же можно получить различными путями. На фиг. 15 показана модификация общей схемы с фиг. 8, при этом машины M1, М 2, , Mn являются теми же, что и до этого, и на всех машинах M1, M2, , Mn одновременно запущено одно и то же приложение (или приложения) 50. Однако к предыдущей схеме добавлена серверная машина X, которая способна выполнять функцию обслуживания и, в частности, инициализацию, очистку и/или синхронизацию структур, конфигураций и ресурсов. В качестве такой серверной машины X можно использовать недорогой бытовой компьютер, например PC, поскольку вычислительная нагрузка на него является невысокой. Как обозначено пунктирными линиями на фиг. 15, можно использовать две серверные машины X и Х+1 с целью дублирования, чтобы повысить общую надежность системы. Если используются две такие серверные машины X и Х+1, то предпочтительно, чтобы они работали как сдвоенная машина в кластере. Дополнительная машина Х+1 является опциональной, что показано пунктирными линиями на фиг. 15. Однако, серверную машину X можно и не добавлять, поскольку ее вычислительная нагрузка может быть распределена между машинами M1, M2, , Mn. Как альтернатива, для реализации функции обслуживания можно на одной из машин использовать базу данных (по схеме "ведущий/ведомый"). На фиг. 16 показана предпочтительная обобщенная процедура, которую необходимо выполнить для инициализации. После того, как будет начато выполнение шага загрузки 161, последовательно рассматриваются команды, которые необходимо выполнить, на предмет выявления всех подпрограмм инициализации, как показано на шаге 162. На языке JAVA это подпрограммы init и clinit (или "методы" по терминологии JAVA). В других языках используют иные термины. Если на шаге 162 выявлена подпрограмма инициализации, то она модифицируется на шаге 163 обычно посредством вставки в подпрограмму дополнительных команд. Как альтернатива, модифицирующие команды могут быть вставлены до подпрограммы. После завершения шага модификации 163 процедура загрузки продолжается, как показано на шаге 164. На фиг. 17 представлена конкретная форма модификации. После начала подпрограммы на шаге 171 структурам, конфигурациям или ресурсам (в терминологии JAVA - классы или объекты), которые необходимо инициализировать, присваивается на шаге 172 имя или тег, которые могут быть использованы глобально всеми машинами. Удобнее всего выполнять это с помощью таблицы, поддерживаемой серверной машиной X, показанной на фиг. 15. Данная таблица также содержит статус класса или объекта, подлежащих инициализации. Как показано на фиг. 17, если на шагах 173 и 174 определено, что глобальное имя еще не инициализировано в другом месте (т.е. на машине, отличной от машины, которая выполняет загрузку), то это означает, что объект или класс могут быть инициализированы нормальным образом путем выполнения шага 176, поскольку это первый такой объект или класс, который необходимо создать. Однако, если на шагах 173 и 174 определено, что глобальное имя уже использовано где-либо, то это означает, что другая машина уже инициализировала данный класс или объект. Как следствие, обычная подпрограмма инициализации полностью прерывается выполнением шага 175. На фиг. 18 проиллюстрирован запрос от машины, производящей загрузку (одна из машин M1,M2Mn), к показанной на фиг. 15 серверной машине X. Работа производящей загрузку машины временно прерывается, как показано на шаге 181, пока не будет получен ответ от машины X, как показано на шаге 182. Фиг. 19 иллюстрирует процессы, выполняемые показанной на фиг. 15 машиной X в ответ на запрос,-7 009926 показанный на фиг. 18 шагом 181. Статус инициализации определяется на шагах 192 и 193, и, если инициализация уже выполнена, то ответ с этим содержанием посылается на запрашивающую машину выполнением шага 194. Аналогично, если статусом инициализации является "не инициализировано", то отсылается соответствующий ответ выполнением шагов 195 и 196. Ждущая запрашивающая машина,созданная на шаге 182, далее может ответить соответствующим образом. В изобретении делается ссылка на сопровождающие приложения, из которых приложения А 1-А 10 показывают актуальный код в отношении полей,приложение В 1 - это типичный фрагмент кода немодифицированной подпрограммы clinit,приложение В 2 - это эквивалент в отношении модифицированной подпрограммы clinit,приложение В 3 - это типичный фрагмент кода из немодифицированной подпрограммы init,приложение В 4 - это эквивалент в отношении модифицированной подпрограммы init,приложение В 5 - это код, альтернативный коду приложения В 2,приложение В 6 - это код, альтернативный коду приложения В 4,приложение В 7 - это исходный код InitClient, который запрашивает "сервер инициализации" о статусе инициализации соответствующего класса или объекта,приложение В 8 - это исходный код InitServer, который получает запрос о статусе инициализации отInitClient и в ответ сообщает соответствующий статус. Аналогично, приложение В 9 - это исходный код примера приложения, которое используется в примерах до/после приложений B1-B6. На фиг. 20 показана процедура, которая должна быть выполнена для модификации подпрограммыclinit в отношении классов так, чтобы произвести конвертацию фрагмента кода приложения B1 во фрагмент кода приложения В 2. Первоначальная загрузка приложения 50 на виртуальную JAVA-машину 72 начинается на шаге 201, и каждая строка кода проверяется выполнением шага 202 для обнаружения тех команд, которые представляют подпрограмму clinit. Как только такие команды обнаружены, подпрограмма clinit модифицируется, как показано в приложении В 2, выполнением шага 203. Как показано на шаге 204, после того, как модификация завершена, продолжается процедура загрузки. Приложения B1 и В 2 - это выборка до и после команды clinit, соответственно. Модифицированный код, который добавлен в данный метод, выделен жирным шрифтом. В примере исходного кода приложения B1 метод clinit создает новый собственный объект и записывает его по адресу памяти (поле) с именем "thisTest". Таким образом, в отсутствии управления загрузкой классов в распределенной среде каждая машина реинициализировала бы один и тот же общий адрес памяти (поле) с различными объектами. Естественно, это совсем не то, чего ожидает программист загружаемого приложения. Тогда, используя преимущества DRT, код приложения модифицируется путем изменения методаclinit во время загрузки в машину. Вносимые изменения (выделенные жирным шрифтом) - это первоначальные команды, которые выполняет метод clinit. Эти добавленные команды проверяют, загружен ли уже этот класс, путем вызова метода isAlreadyLoaded, который возвращает истинное или ложное значение в соответствии с состоянием загрузки данного класса. Метод isAlreadyLoaded средства DRT может опционально использовать для определения статуса загрузки данного класса аргумент, который представляет уникальный идентификатор для данного класса(см. приложения В 5 и В 6), например, имя класса, или объект класса, представляющий данный класс, или уникальный номер, представляющий данный класс на всех машинах. Таким образом, данное средствоDRT может поддерживать одновременную загрузку множественных классов без ошибок относительно того, какой из множественных классов уже загружен, а какой - нет, используя уникальный идентификатор каждого класса для сверки с нужной записью в таблице isAlreadyLoaded. Средство DRT может определить статус загрузки этого класса несколькими способами. Предпочтительно оно может опрашивать каждую машину по очереди, загружен ли данный класс, и, если какаялибо из машин отвечает "истинно", то возвращать значение "истинно", в противном случае - "ложно". Как альтернатива, средство DRT на локальной машине может обращаться к общей таблице записей (возможно, на отдельной машине (например, на машине X), или к согласованной общей таблице записей на локальной машине, или к базе данных), чтобы определить, загружен уже данный класс или нет. Если средство DRT возвращает значение "ложно", то это означает, что данный класс еще не был загружен ни на одну из машин в распределенной среде, и, следовательно, данное выполнение следует рассматривать как первое и исходное. Как следствие, средство DRT должно обновить запись "isAlreadyLoaded" для данного класса в общей таблице записей, придав ей значение "истинно", чтобы все последующие запросы isAlreadyLoaded на всех других машинах, включая данную машину, возвращали значение "истинно". Таким образом, если DRT.isAlreadyLoaded возвращает значение "ложно", то модифицированный метод clinit продолжает работать с исходным блоком кода, который теперь отслеживает три вставленные команды. С другой стороны, если средство DRT возвращает значение "истинно", то это означает, что данный класс уже был загружен в распределенную среду, что записано в общей таблице записей загруженных классов. В этом случае исходный блок кода не должен выполняться, поскольку он перезапишет уже инициализированные адреса памяти, и т.д. Таким образом, если DRT возвращает значение "истинно", то-8 009926 вставленные три команды предотвращают выполнение исходного кода и возвращают непосредственно в программу приложения. Эквивалентная процедура для подпрограмм init в отношении объектов показана на фиг. 21, где шаги 212 и 213 эквивалентны шагам 202 и 203 на фиг. 20. В результате код приложения В 3 конвертируется в код приложения В 4. Модификация, подобная используемой для clinit, используется для init. Блок init программы приложения (или блоки, поскольку их может быть несколько в отличие от clinit) обнаруживается (или обнаруживаются), как показано на шаге 212, и модифицируется, как показано на шаге 213, для того, чтобы согласовано функционировать во всей распределенной среде. В примере приложения B3 init-команды программы приложения инициализируют адрес памяти(поле) с меткой времени загрузки. Приложение могло бы использовать это, например, для записи времени создания данного объекта. Ясно, что в распределенной среде, где равноправные объекты могут быть загружены в разное время, необходима особая обработка для того, чтобы гарантировать, что метка времени первого загруженного равноправного объекта не будет перезаписана последующими равноправными объектами. Последовательность деассемблированных команд после имевшей место модификации представлена в приложении В 4, причем модифицированные/вставленные команды выделены жирным шрифтом. Для модификации init, в отличие от модификации clinit, часто необходимо размещать модифицирующие команды после команды "invokespecial", вместо размещения их в самом начале. Причины этого определяются свойствами виртуальной JAVA-машины. В других языках часто имеются похожие тонкие особенности построения. Дана фундаментальная концепция тестирования для определения, прошла ли уже инициализация или она не выполняется, и если так, то не производить какую бы то ни было дальнейшую инициализацию; данная концепция может быть реализована несколькими различными вариантами. В первом варианте отдельная машина, например машина М 2, загружает класс или объект в себя, а затем загружает в каждую из других машин M1, M3, , Mn (последовательно или одновременно). Согласно данной схеме, которую можно назвать "ведущий"/"ведомый" ("master/slave"), каждая из машинM1, M3, , Mn загружает то, что выдает ей машина М 2. В подварианте этой схемы "ведущий"/"ведомый", машина М 2 загружает в себя подпрограммуclinit в немодифицированной форме, а затем модифицирует данный класс путем полного удаления подпрограммы инициализации и загружает этот модифицированный класс в другие машины. Таким образом, в данном примере модификация - это не обход подпрограммы инициализации, а ее удаление на всех машинах, кроме одной. В другом варианте каждая машина получает подпрограмму инициализации, но модифицирует ее и загружает модифицированную подпрограмму в себя. Это позволяет производить модификацию каждой машиной немного иначе, оптимизируя ее на основании архитектуры и операционной системы данной машины, и все же эта модификация соответствует всем остальным схожим модификациям. Согласно еще одной схеме отдельная машина, скажем M1, загружает этот класс, и все остальные машины М 2, М 3, , Mn производят модификацию, чтобы удалить подпрограмму инициализации и загрузить модифицированную версию. Во всех примерах передача данных может быть или "ветвеобразной" (т.е. М 2 передает данные каждой из машин M1, М 3, М 4 и т.д. напрямую), или "каскадной" или "последовательной" (т.е. М 2 передаетM1, которая затем передает М 3, которая затем передает М 4, и т.д.). Согласно еще одной схеме первоначальная машина, например М 2, может выполнить начальную загрузку, а затем создать таблицу, в которой перечислены все классы, загруженные машиной М 2. Эту таблицу затем передают на все другие машины (путем ветвеобразной или каскадной передачи). Если затем какая-либо машина, отличная от М 2, требует доступ к классу, включенному в эту таблицу, то она посылает на М 2 запрос о предоставлении необходимой информации. Таким образом, информация, предоставленная машине Mn, в общем случае отличается от начального состояния, загруженного в машину М 2. В вышеописанных условиях необходимо, чтобы каждая из записей этой таблицы сопровождалась счетчиком, увеличивающимся каждый раз при загрузке класса. Таким образом, когда получен запрос данных, в ответ на запрос поступает и содержимое класса, и отсчет соответствующего счетчика. Этот режим "по запросу" увеличивает непроизводительные расходы каждого компьютера, однако уменьшает объем передаваемых данных в сети связи, соединяющей эти компьютеры. Согласно еще одной схеме машины M1-Mn могут посылать все запросы на загрузку на дополнительную машину X (показана на фиг. 15), которая выполняет модификацию посредством любого из вышеописанных способов и возвращает модифицированный класс на каждую из машин M1-Mn, которые затем загружают этот класс локально. В этой схеме машины M1-Mn не поддерживают таблицу записей для любого класса, вместо этого они пересылают все запросы на загрузку машине X, которая поддерживает таблицу загруженных классов и возвращает модифицированный класс на каждую машину в зависимости от того, в первый раз данный класс загружается на машины М 1Mn или нет. Объем правовой охраны настоящего изобретения включает в себя любые модификации, выполняемые машиной X.-9 009926 Обратимся опять к фиг. 14. На языке JAVA подпрограмма clinit инициализации отрабатывает только один раз, когда происходит загрузка файла 50 А данного класса. Однако подпрограмма init инициализации отрабатывает часто, например, каждый раз, когда происходит создание нового объекта 50 Х, 50Y или 50Z. К тому же загрузка классов происходит ранее загрузки объектов, так что в программе приложения, показанной на фиг. 14 и имеющей только один класс 50 А и три объекта 50X-50Z, в первую очередь происходит загрузка первого класса 50 А, затем загрузка первого объекта 50 Х, затем второго объекта 50Y и, наконец, происходит загрузка третьего объекта 50Z. Если, как на фиг. 14, существует только одиночный компьютер или машина 72, то при запуске подпрограмм, которые должны быть выполнены во время процедуры загрузки, не возникает конфликтов или противоречий, поскольку эта показанная на фиг. 14 одиночная машина может легко отслеживать, необходимы ли конкретные объекты 50X-50Z в будущем для программы 50. Это достигается с помощью поддержки "подсчета идентификаторов" или аналогичной процедуры. Этот подсчет отслеживает число мест в исполняемом коде, в которых есть ссылка на какой-либо конкретный объект. Если подсчет идентификаторов для какого-либо конкретного объекта дает нулевое значение, то это значит, что нигде в исполняемом коде нет ссылок на этот объект. В этом случае такой объект называют "финализируемым" (finalizable). Если достигнуто такое состояние, то этот объект может быть безопасно удален (или очищен, или финализирован), поскольку он больше не нужен. Та же процедура с соответствующими поправками применима к классам. В частности, программисту, который создает программу с использованием языка и архитектуры JAVA, не нужно писать какой-либо специфический код, чтобы обеспечить эту очистку,удаление или финализацию. Вместо этого отдельная виртуальная машина JAVA 72 может отслеживать подсчеты идентификаторов классов и объектов и выполнять очистку (или выполнять финализацию) при необходимости незаметным образом. Однако на схеме, показанной на фиг. 8 (а также на фиг. 31-33), есть множество отдельных компьютеров (или машин) M1, М 2, , Mn, каждый из которых соединен сетью 53 связи и каждый из которых снабжен модификатором 51 (как на фиг. 5, что реализовано средством DRT 71 на фиг. 8), на которые загружена общая программа 50 приложения. По существу, модификатор 51 или средство DRT 71 модифицирует код 50 приложения для выполнения подпрограмм очистки на всем множестве отдельных машинM1, M2, , Mn. Таким образом, отсюда следует, что в такой вычислительной среде необходимо удостовериться, что каждая из отдельных машин финализирована непротиворечивым образом (относительно других машин). В частности, в то время как одна какая-то машина (например, М 3) может более не иметь обращений к объекту или классу, другая машина (скажем, М 5) может по-прежнему иметь необходимость обратиться к этому объекту или классу в будущем. Таким образом, если этот объект или класс был бы удален с машины М 3, то, если бы М 5 должна была произвести запись в этот объект и изменить его значение, это изменение значения не могло бы быть распространено на все машины M1, M2, , Mn, поскольку машина М 3 не содержала бы соответствующий объект в своей локальной памяти. Более того, если бы машина М 3 выполнила подпрограмму очистки на данном объекте или классе, то эта подпрограмма очистки произвела бы очистку не только для данного объекта на этой машине, но также для всех равноправных объектов на всех других машинах. Таким образом, этот объект на машине М 5 был бы объявлен недействительным. Таким образом, идентичного, по существу, содержимого памяти машин M1, M2, , Mn, необходимого для одновременной работы одной и той же программы приложения, достичь бы не удалось. Чтобы обеспечить непротиворечивую финализацию или очистку, программу 50 приложения подвергают проверке для обнаружения программных шагов, которые определяют подпрограмму очистки. Данная проверка может иметь место или до загрузки, или во время процедуры загрузки, или даже после процедуры загрузки (однако до выполнения соответствующей релевантной части кода 50 приложения). Это можно сравнить с процедурой компиляции, понимая, что термин "компиляция" обычно подразумевает изменение кода или языка, например, из исходника в объектный код или из одного языка в другой. Однако в настоящем случае термин "компиляция" (и его грамматические эквиваленты) не ограничен и может содержать широчайшие модификации в рамках самого кода или языка. Как следствие, при вышеупомянутой проверке первоначально идет поиск подпрограмм очистки, а когда они найдены, происходит вставка модифицирующего кода для создания модифицированной подпрограммы очистки. Эта модифицированная подпрограмма должна прервать подпрограмму очистки на любой конкретной машине, если класс или объект, который нужно удалить, не помечен для удаления всеми другими машинами. Данная модификация и загрузка могут быть выполнены в нескольких различных режимах. В связи с этим, сделана ссылка на приложение С, в котором приведены примеры различных режимов очистки или финализации. Так, в одном режиме средство DRT 71/1 на машине, производящей загрузку, в данном случаеJVM1, опрашивает средства DRT 71/271/n всех других машин М 2Mn, использован ли (т.е. не помечен для удаления), например, первый объект 50 Х любой другой машиной М 2Mn. Если ответ на этот вопрос "да", то далее обычная процедура очистки отключается или запрещается для первого объекта 50 Х на машине JVM1. Если ответ "нет" (т.е. первый объект 50 Х помечен для удаления на всех других машинах), то происходит выполнение обычной процедуры очистки, а первый объект 50 Х удаляется не- 10009926 только на машине JVM1, но и на всех других машинах М 2Mn. Предпочтительно задача очистки располагается на последней машине M1, маркирующей объект или класс на удаление. На фиг. 22 показана предпочтительная обобщенная процедура, которую необходимо выполнить для финализации. После того как было начато выполнение загрузки 161 А, команды, которые необходимо выполнить, рассматриваются последовательно, а все подпрограммы очистки выявляются, как показано на шаге 162 А. На языке JAVA это является подпрограммой "finalize" (или "методом", по терминологииJAVA). В других языках используют иные термины. Если обнаружена подпрограмма очистки, то она модифицируется на шаге 163 А, обычно путем вставки в подпрограмму дополнительных команд. Как альтернатива, модифицирующие команды могут быть вставлены перед подпрограммой. После завершения модификации процедура загрузки продолжается, как показано на шаге 164 А. На фиг. 23 изображена конкретная форма модификации. Во-первых, структурам, конфигурациям и ресурсам (на языке JAVA они называются классами или объектами) 50 А, 50 Х, , 50Y, которые являются потенциальными кандидатами на очистку, уже присвоено имя или тег, которые могут быть использованы глобально всеми машинами M1, M2, , Mn, как показано на шаге 172 А. Предпочтительно это происходит во время первоначальной инициализации этих классов или объектов. Лучше всего выполнять это с помощью таблицы, поддерживаемой серверной машиной X. Данная таблица также содержит "статус очистки" этого класса или объекта. В предпочтительном варианте эта таблица также содержит счетчик,который записывает число машин, пометивших данный ресурс для удаления. Тогда общее значение счетчика, меньшее чем (n-1), обозначает статус "не очищать" для этого ресурса как сетевого целого. Как показано на фиг. 23, если глобальное имя не помечено для удаления на всех других машинах(т.е. на всех, кроме машины, предлагающей выполнить подпрограмму очистки), то это означает, что предложенная подпрограмма очистки объекта или класса должна быть прервана, поскольку этот объект или класс еще необходим, как показано на шаге 175 А. Однако если глобальное имя помечено для удаления на всех машинах, то это означает, что ни одна другая машина не нуждается в этом классе или объекте. Как следствие, обычная подпрограмма очистки,показанная на шаге 176 А, может и должна быть выполнена. На фиг. 24 показан запрос серверной машине X, сделанный машиной, которая предлагает выполнение подпрограммы очистки (одна из машин M1, M2, , Mn). Работа этой предлагающей машины временно прерывается, как показано на шаге 181 А и 182 А, до тех пор, пока не будет получен ответ от машины X, что показано на шаге 182 А. На фиг. 25 показаны процессы, выполняемые машиной X в ответ на такой запрос. Статус очистки определен, как видно на шаге 192 А, и если ответ "нет", то названный ресурс не помечают для удаления на (n-1) машинах (т.е. он где-либо используется), ответ с этим содержанием отсылается на запрашивающую машину 194 А, однако счетчик "помечен для удаления" увеличивается на единицу, как показано на шаге 197 А. Аналогично, если ответ - "да", то отсылается соответствующий ответ, как показано на шаге 195 А. Далее ожидающая запрашивающая машина 182 А может ответить соответствующим образом. Как показано пунктирными линиями на фиг. 25, предпочтительно, чтобы в дополнение к ответу "да" на шаге 195 А была обновлена общая таблица так, чтобы статус глобально поименованного ресурса был изменен на "очищен", что показано на шаге 196 А. Обратимся опять к фиг. 14. Одиночная машина, показанная на фиг. 14, может легко выполнить синхронизацию конкретных объектов 50X-50Z, если так было определено программистом в использовании подпрограммы синхронизации. Поскольку каждый объект существует только локально, одиночная виртуальная JAVA-машина 72 может обеспечить правильную синхронизацию объекта, как было определено программистом, и, таким образом, обеспечить использование объекта только одной частью исполняемого кода в каждый отдельный момент времени. Если предполагается использовать тот же самый объект другой частью исполняемого кода, то возможная конкуренция устраняется виртуальной JAVA-машиной 72 таким образом, что другие исполняемые части программы приложения должны ждать, пока не завершится ее первая часть. Та же процедура с соответствующими поправками применима к классам 50 А. В частности, программисту, создающему программу с использованием языка и архитектуры JAVA, нужно просто использовать подпрограмму (подпрограммы) синхронизации, чтобы обеспечить это устранение конфликтной ситуации. Таким образом, одиночная виртуальная JAVA-машина может отслеживать использование классов и объектов и избегать при необходимости любых соответствующих проблем незаметным образом. Процесс, обеспечивающий эксклюзивное использование только одного объекта или класса, называется "синхронизацией". На языке JAVA команды "monitorenter" и "monitorexit" обозначают конец и начало подпрограммы синхронизации, которая имеет своим результатом, соответственно, получение и освобождение "блокиратора", предотвращающего конфликтную ситуацию в отношении какого-либо ресурса. Однако на схеме, показанной на фиг. 8 (а также на фиг. 31-33), есть группа соединенных сетью 53 связи отдельных компьютеров или машин M1, M2, , Mn, каждый из которых снабжен модификатором 51 (как на фиг. 5, что реализовано показанным на фиг. 8 средством DRT 71). На эти компьютеры загружена общая программа 50 приложения. По существу, модификатор 51 или средство DRT 71 обеспечива- 11009926 ет следующее условие - если часть программы 50 приложения, запущенной на одной из машин, эксклюзивным образом использует (например, посредством синхронизации) какой-либо конкретный ресурс,например, объекты 50X-50Z или класс 50 А, то ни одна другая машина М 2Mn не будет использовать соответствующий ресурс в своей локальной памяти. В частности, тогда как одна машина (например, М 3) эксклюзивным образом использует какой-либо объект или класс, другая машина (например, М 5) может также получить команду от исполняемого ею кода эксклюзивным образом использовать тот же объект или класс в то же самое время. В результате,если бы этот объект или класс эксклюзивным образом использовался обеими машинами, то поведение объекта и приложения как целого стало бы неопределенным, т.е. из-за отсутствия правильного эксклюзивного использования объекта, явно заданного программистом, возможно возникновение постоянной несовместимости между машинами М 5 и М 3. Таким образом, идентичного, по существу, содержимого памяти машин M1, M2, , Mn, необходимого для одновременной работы одной и той же программы приложения, достичь бы не удалось. Чтобы обеспечить согласованную синхронизацию, программа приложения подвергается анализу для выявления шагов, определяющих подпрограмму синхронизации. Данная проверка может иметь место или до загрузки, или во время процедуры загрузки, или даже после процедуры загрузки (однако до выполнения соответствующей релевантной части кода программы). Это можно сравнить с процедурой компиляции, понимая, что термин "компиляция" обычно подразумевает изменение кода или языка, например, из исходника в объектный код или из одного языка в другой. Однако в настоящем случае термин"компиляция" (и его грамматические эквиваленты) не ограничен и может содержать широчайшие модификации в рамках самого кода или языка. Далее сделаны ссылки на приложение D, в котором приложение D1 - это типичный фрагмент кода из немодифицированной подпрограммы синхронизации,и приложение D2 - это эквивалент в отношении модифицированной подпрограммы синхронизации. Приложения D1 и D2 - это выборка до и после подпрограммы синхронизации соответственно. Модифицированный код, который вставлен в этот метод, выделен жирным шрифтом. В образце исходного кода приложения D1 код увеличивает общий адрес памяти (счетчик) в рамках оператора синхронизации. Цель этого оператора синхронизации - обеспечить безопасность потоков операции приращения в многопоточных приложениях. Так, без управления синхронизацией в распределенной среде каждая машина выполняла бы синхронизацию изолированно, при этом возможно увеличивая общий счетчик, что может привести к возникновению условия состязания сигналов и к несогласованности памяти. Естественно, это совсем не то, чего ожидает программист программы приложения. Таким образом, используя преимущества DRT, код приложения модифицируется во время загрузки в машину путем изменения подпрограммы синхронизации. Вносимые изменения (выделенные жирным шрифтом) - это первоначальные команды и завершающие команды, которые выполняет подпрограмма синхронизации. Эти добавленные команды проводят дополнительную синхронизацию на всех других машинах в распределенной среде, способствуя, таким образом, сохранению синхронного поведения программы приложения на множестве машин. Метод acquireLock средства DRT получает аргумент, который представляет уникальный идентификатор этого объекта (см. приложение D2), например, имя объекта, ссылку на объект, о котором идет речь, или уникальный номер, представляющий этот объект на всех узлах, с целью использования его для получения глобального блокиратора для конкретного объекта. Таким образом, средство DRT может поддерживать одновременную синхронизацию множества объектов без конфликтов относительно того, какие из множества объектов уже находятся в процессе синхронизации, а какие - нет, используя уникальный идентификатор каждого объекта для сверки с нужной записью в общей таблице синхронизации. Средство DRT может определить состояние синхронизации этого объекта несколькими способами. Предпочтительно оно может опросить каждую машину по очереди, идет ли в настоящее время на ней синхронизация локальной копии этого объекта, и, если какая-либо из машин возвращает ответ "истинно", то ожидать, когда этот объект станет несинхронизируемым, в противном случае синхронизировать этот объект локально. Как альтернатива, средство DRT на локальной машине может обратиться к общей таблице записей (возможно, на отдельной машине (например, на машине X), или к согласованной общей таблице записей на локальной машине, или к базе данных) для того, чтобы определить, помечен ли уже этот объект, как синхронизируемый любой другой машиной, и если это так, то ожидать, пока статус объекта не изменится на "несинхронизируемый", а затем получить блокиратор путем пометки объекта как синхронизируемого, в противном случае получить блокиратор, пометив этот объект как синхронизируемый этой машиной. Если средство DRT определяет, что ни одна другая машина не имеет в данный момент блокиратора для этого объекта (т.е. ни одна другая машина не синхронизирует этот объект), то оно получает блокиратор для этого объекта на всех других машинах, например, путем изменения соответствующей записи в общей таблице состояний синхронизации или, как альтернатива, последовательно получает блокиратор на всех других машинах в дополнение к текущей машине. Выполнение исходного синхронизированного- 12009926 блока кода может быть начато только, если эта машина успешно подтвердит, что ни одна другая машина на данный момент не синхронизирует этот объект, и она уже провела локальную синхронизацию. С другой стороны, если средство DRT определяет, что другая машина уже синхронизировала данный объект, тогда эта машина должна отложить выполнение исходного блока кода синхронизации до тех пор, пока средство DRT не сможет подтвердить, что никакая другая машина в настоящий момент не выполняет оператор синхронизации для данного объекта и что эта машина, соответственно, выполнила синхронизацию данного объекта локально. В этом случае не допускается выполнять исходный блок кода,пока эта машина не сможет гарантировать, что никакая другая машина не выполняет оператор синхронизации для данного объекта, поскольку это может исказить данный объект на всех участвующих машинах из-за возникновения условия состязания сигналов, несогласованности памяти и т.д., как результат одновременного выполнения операторов синхронизации. Таким образом, когда средство DRT определяет, что этот объект в настоящее время "синхронизируется", средство DRT предотвращает исполнение исходного блока кода путем приостановки выполнения операции "acquireLock" до тех пор, пока соответствующая операция "acquireLock" не будет выполнена текущим владельцем блокиратора. Таким образом, после выполнения операции "releaseLock" машина, которая в настоящий момент"владеет" блокиратором (т.е. выполняет оператор синхронизации), обозначает завершение своего оператора синхронизации, например, путем пометки данного объекта как "несинхронизируемого" в общей таблице состояний синхронизации или, как альтернатива, последовательно снимая блокираторы, полученные на всех других машинах. На этом этапе любая другая машина, ожидающая начала выполнения соответствующего оператора синхронизации, может далее запросить владение блокиратором этого объекта путем возобновления выполнения своей отложенной (т.е. задержанной) операции "acquireLock",например, помечая себя в общей таблице состояний синхронизации как выполняющую оператор синхронизации для этого объекта, или, как альтернатива, последовательно получая локальные блокираторы на каждой из других машин. Таким образом, используя преимущества средства DRT, во время загрузки в эту машину код приложения модифицируют путем изменения подпрограммы синхронизации (состоящей из начальной"monitorenter" и завершающей "monitorexit" команды/команд). Вносимые изменения (выделенные жирным шрифтом) - это первоначальные команды, которые выполняет подпрограмма синхронизации. Эти добавленные команды проверяют, получен ли уже этот блокиратор другой машиной. Если этот блокиратор еще не получен другой машиной, то средство DRT данной машины извещает все другие машины, что эта машина получила блокиратор, и, таким образом, удерживает другие машины от выполнения подпрограмм синхронизации для этого блокиратора. Средство DRT может записывать статус блокиратора этих машин разными альтернативными способами, например: 1. В соответствии со входом в подпрограмму синхронизации средство DRT запрашивает у каждой из машин по отдельности подтверждение, получен ли уже блокиратор. Если так, то средство DRT приостанавливает выполнение подпрограммы синхронизации до тех пор, пока все другие машины не перестанут "владеть" блокиратором для этого ресурса или объекта. В противном случае средство DRT выполняет эту подпрограмму синхронизации. 2. В соответствии со входом в подпрограмму синхронизации, средство DRT обращается к общей таблице записей (например, к общей базе данных или к копии общей таблицы на каждой из участвующих машин), которые определяют, "владеет" ли блокиратором какая-либо из машин в настоящий момент. Если это так, то средство DRT приостанавливает выполнение подпрограммы синхронизации на этой машине до тех пор, пока все другие машины не перестанут "владеть" блокиратором для этого объекта. В противном случае средство DRT записывает эту машину в общую таблицу (или в таблицы, если существует множество таблиц записей, например, на множестве машин) в качестве владельца этого блокиратора, а затем выполняет подпрограмму синхронизации. Аналогично, когда блокиратор снят, т.е. когда выполнение подпрограммы синхронизации завершено, средство DRT может убрать запись о статусе блокиратора машин несколькими альтернативными способами, например: 1. В соответствии с выходом из подпрограммы синхронизации средство DRT извещает каждую другую машину по отдельности, что она более не "владеет" блокиратором. 2. В соответствии с выходом из подпрограммы синхронизации средство DRT обновляет запись для этого заблокированного ресурса или объекта в общей таблице (таблицах) записей так, что данная машина более не является указанной в качестве владельца блокиратора. Более того, средство DRT может ставить в очередь машины, желающие получить заблокированный объект, множеством альтернативных способов, например: 1. В соответствии со входом в подпрограмму синхронизации, средство DRT извещает текущего владельца заблокированного объекта о том, что некоторая конкретная машина хотела бы получить данный блокиратор после его освобождения текущей машиной-владельцем. Далее эта конкретная машина,если нет других ожидающих машин, сохраняет запись об интересе данной конкретной машины в таблице, которая после завершения синхронизирующей подпрограммы заблокированного объекта далее изве- 13009926 щает ждущую машину, что та может получить этот заблокированный объект и, таким образом, начать выполнение своей подпрограммы синхронизации. 2. В соответствии со входом в подпрограмму синхронизации, средство DRT извещает текущего владельца заблокированного объекта, что некоторая конкретная машина (например, машина М 6) хотела бы получить блокиратор после его освобождения этой машиной (например, машиной М 4). Если эта машина М 4 после просмотра своих записей ждущих машин для этого заблокированного объекта обнаруживает, что уже одна или более машин находятся в ожидании, то она или добавляет машину М 6 в конец списка машин, ожидающих получения данного заблокированного объекта, или, как альтернатива, перенаправляет запрос от машины М 6 первой ждущей машине, или любой другой ждущей машине, которая,в свою очередь, записывает машину М 6 в свою таблицу записей. 3. В соответствии со входом в подпрограмму синхронизации, средство DRT записывает себя в общую таблицу (таблицы) записей (например, в таблицу, хранящуюся в общей базе данных, доступной всем машинам, или во множество отдельных таблиц, которые, по существу, подобны). Кроме того, средство DRT может известить другие машины, ожидающие очереди на получение этого блокиратора, в соответствии с выходом из подпрограммы синхронизации этой машины, следующими альтернативными способами, например: 1. В соответствии с выходом из подпрограммы синхронизации средство DRT извещает одну из ждущих машин (например, эту первую машину в очереди ждущих машин) о том, что блокиратор освобожден. 2. В соответствии с выходом из подпрограммы синхронизации средство DRT извещает одну из ждущих машин (например, первую машину в очереди ждущих машин) о том, что блокиратор освобожден, и дополнительно обеспечивает копию всей очереди машин (например, вторая и последующие машины, ждущие этого блокиратора). Таким образом, вторая машина наследует список ждущих машин от первой машины, обеспечивая посредством этого непрерывность очереди ждущих машин, поскольку каждая последующая машина в списке по очереди получает, а затем освобождает блокиратор. В течение вышеупомянутой проверки сначала производится поиск команд (или методов) "monitorenter" и "monitor exit", а когда они выявлены, происходит вставка модифицирующего кода с целью создания модифицированной подпрограммы синхронизации. Эта модифицированная подпрограмма получает и освобождает блокиратор. Данная модификация и загрузка могут быть выполнены в нескольких различных режимах. Более подробная информация приведена в приложении D. На фиг. 26 показана предпочтительная общая процедура, которую необходимо выполнить в отношении синхронизации. После того как было начато выполнение загрузки 161 В, последовательно рассматриваются команды, которые необходимо выполнить, и выявляются все подпрограммы синхронизации, как показано на шаге 162 В. На языке JAVA - это команды "monitor enter" и "monitor exit". В других языках используют иные термины. Если выявлена подпрограмма синхронизации, то она обычно модифицируется путем вставки дополнительных команд в подпрограмму. Как альтернатива, модифицирующие команды могут быть вставлены до подпрограммы. Когда модификация завершена, продолжается процедура загрузки. Модификации предпочтительно принимают форму операции "установить блокиратор на всех других машинах" и форму модификации "снять блокиратор на всех других машинах", как показано на шаге 163 В. На фиг. 27 изображена конкретная форма модификации. Во-первых, структурам, конфигурациям и ресурсам (в языке JAVA они называются классами или объектами, например 50 А, 50X-50Y), которые необходимо синхронизировать, уже присвоено имя или тег, которые могут быть использованы глобально всеми машинами, как показано на шаге 172 В. Предпочтительно это происходит во время первоначальной инициализации этих классов или объектов. Лучше всего выполнять это с помощью таблицы, поддерживаемой серверной машиной X. Данная таблица также содержит статус синхронизации этого класса или объекта. В предпочтительном случае эта таблица также содержит схему очереди, которая хранит идентификаторы машин, запросивших использование данного ресурса. Как показано на фиг. 27 шагом 173 В, далее на машину X посылают запрос "получить блокиратор",после чего машина, пославшая запрос, ждет подтверждения о получении блокиратора, как показано на шаге 174 В. Таким образом, если глобальное имя уже заблокировано (т.е. соответствующий ресурс используется машиной, отличной от той, которая послала запрос на получение блокиратора), то это означает, что предложенная подпрограмма синхронизации этого объекта или класса должна быть приостановлена до тех пор, пока этот объект или класс не будет разблокирован текущим владельцем. Как альтернатива, если глобальное имя не заблокировано, то это означает, что никакая другая машина не использует в данный момент этот класс или объект, и подтверждение о получении блокиратора приходит немедленно. После получения подтверждения о получении блокиратора подпрограмме синхронизации разрешено продолжить работу, как показано на шаге 175 В. На фиг. 28 показана процедура, выполняемая запросившей снятия блокиратора машиной, на которой запущена программа приложения. Начальный этап показан на шаге 181 В. Работа этой предлагающей машины временно прервана на шагах 183 В, 184 В до тех пор, пока не получен ответ от машины X, соответственно шагу 184 В, и далее выполнение возобновляется, как показано на шаге 185 В. Опционально, и- 14009926 как показано на шаге 182 В, машина, запрашивающая снятие блокиратора, должна выполнить поиск"глобального имени" для этого блокиратора до отправки запроса на машину X. Таким образом, множество блокираторов на множестве машин может быть установлено и снято без взаимных помех. На фиг. 29 показаны процессы, выполняемые машиной X в ответ на запрос "получить блокиратор"(фиг. 27). После получения запроса "получить блокиратор" на шаге 191 В, статус блокиратора определяют на шагах 192 В и 193 В, и если "нет", то названный ресурс не свободен, идентификатор запрашивающей машины добавляется на шаге 194 В к очереди (или формирует ее) ждущих запросов на получение. Как альтернатива, если ответ "да", то названный ресурс свободен и соответствующий ответ послан на шаге 197 В. Ждущие запрашивающие машины далее могут соответственно выполнить подпрограмму синхронизации путем выполнения шага 175 В на фиг. 27. В дополнение к ответу "да", общая таблица обновляется на шаге 196 В, так что статус глобально поименованного ресурса меняется на "заблокирован". На фиг. 30 показаны процессы, выполняемые машиной X в ответ на запрос "снять блокиратор" на фиг. 28. После получения запроса "снять блокиратор" на шаге 201 машина X опционально и предпочтительно подтверждает, что машина, запросившая снятие (освобождение) блокиратора, на самом деле является текущим "владельцем блокиратора", как показано на шаге 202. Далее, на шаге 203 определяют статус очереди, и, если никто не ждет получения этого блокиратора, то машина X помечает этот блокиратор как "свободный" в общей таблице, как показано на шаге 207, и опционально посылает подтверждение об освобождении блокиратора запрашивающей машине, как показано на шаге 208. Это позволяет запрашивающей машине выполнить шаг 185 В фиг. 28. Как альтернатива, если "да", т.е. если другие машины ждут получения этого блокиратора, то машина X помечает этот блокиратор как полученный в данный момент времени следующей машиной в очереди, как показано на шаге 204, и затем посылает подтверждение о получении блокиратора стоящей в очереди машине на шаге 205, а, следовательно, удаляет нового владельца блокиратора из очереди ждущих машин, как показано на шаге 206. Обратимся теперь к фиг. 31-33; здесь показаны два портативных компьютера 101 и 102. Эти компьютеры 101 и 102 необязательно являются идентичными - один из них может быть IBM-совместимым или IBM-клоном, а другой может быть компьютером APPLE. Эти компьютеры 101 и 102 имеют два экрана 105, 115, две клавиатуры 106, 116, но одну мышь 107. Эти две машины 101, 102 связаны одиночным коаксиальным кабелем или витой парой 314. Две простые программы приложения загружены в каждую из машин 101, 102, причем эти программы модифицируются при загрузке вышеописанным способом. Согласно этому варианту первое приложение - это простая вычислительная программа, обеспечивающая вывод изображения калькулятора 108 на экран 105. Вторая программа - это графическая программа, которая выводит изображение четырех окрашенных блоков 109, которые имеют разные цвета и перемещаются случайным образом в прямоугольной рамке 310. Опять же, после загрузки рамка 310 выводится на экран 105. Каждое приложение работает независимо, поэтому блоки 109 находятся в случайном движении по экрану 105, в то время как цифры калькулятора 108 могут быть выбраны (с помощью мыши 107) вместе с математическим оператором (например, сложение или умножение), а калькулятор отображает результат. Мышь 107 может быть использована для "захвата" рамки 310 и перемещения ее вправо через экран 105 на экран 115 до положения, изображенного на фиг. 32. В этой схеме приложение-калькулятор выполняется на машине 101, в то время как графическое приложение, выводящее рамку 310 на экран, выполняется на машине 102. Однако, как показано на фиг. 33, с помощью мыши можно перетащить вправо калькулятор 108, показанный на фиг. 32, так чтобы по одной части калькулятора 108 было выведено на каждом из экранов 105, 115. Аналогично, рамку 310, показанную на фиг. 32, можно перетащить с помощью мыши 107 влево, чтобы рамка 310 была частично отображена на каждом из экранов 105, 115, как показано на фиг. 33. В данной схеме часть процессов калькулятора выполняет машина 101, а часть - машина 102, в то время как часть графического приложения выполняет машина 101, а другую часть выполняет машина 102. В данном патенте описаны лишь некоторые варианты изобретения. Однако следует понимать, что их модификации, очевидные специалистам данной области техники, также подпадают под объем правовой охраны настоящего изобретения. Например, указание на JAVA подразумевает как язык JAVA, так и платформу и архитектуру JAVA. Специалисты, работающие в области программирования, знают, что если дополнительный код или команды добавлены в существующий код или набор команд для их модификации, то существующий код или набор команд вполне может потребовать дополнительной модификации (например, путем перенумерации последовательных команд), так что необходимо учитывать соответствующие смещения, ветвления, атрибуты, маркировки и т.д. Аналогично, в языке JAVA адреса памяти включают в себя, например, как поля, так и регулярные типы. Вышеприведенное описание рассматривает поля. Однако следует понимать, что изменения, требуемые для регулярных типов, являются, по существу, теми же самыми с соответствующими поправками. Также настоящее изобретение в равной степени применимо к разным языкам программирования(включая процедурные, декларативные и объектно-ориентированные), аналогичным языку JAVA, вклю- 15009926 чая платформу и архитектуру Micrsoft.NET (Visual Basic, Visual С/С, and C), FORTRAN, C/C, COBOL, BASIC и т.д. Вышеупомянутый вариант, в котором модифицируется код JAVA подпрограммы инициализации,основан на предположении, что или система исполнения (например, JAVA HOTSPOT VIRTUAL MACHINE, написанная на С или JAVA), или операционная система (LINUX, написанная на С и Ассемблер,например) каждой из машин М 1Mn будет вызывать подпрограмму инициализации JAVA. Можно не изменять подпрограмму инициализации JAVA, а вместо этого изменить подпрограмму LINUX илиHOTSPOT, которая вызывает подпрограмму инициализации JAVA, так что если объект или класс уже загружен, то подпрограмма инициализации JAVA не вызывается. Для того чтобы принять такую схему,термин "подпрограмма инициализации" должен пониматься как включающий в себя и подпрограмму инициализации JAVA, и "комбинацию" подпрограммы инициализации JAVA и фрагментов кода LINUX или HOTSPOT, которые вызывают или инициируют подпрограмму инициализации JAVA. Вышеупомянутый вариант, в котором модифицируется код подпрограммы финализации или очистки JAVA, основан на предположении, что или система исполнения (например, JAVA HOTSPOT VIRTUAL MACHINE, написанная на С или JAVA), или операционная система (LINUX, написанная на С и Ассемблер, например) каждой из машин М 1Mn будет вызывать подпрограмму финализации JAVA. Можно не изменять подпрограмму финализации JAVA, а вместо этого изменить подпрограмму LINUX или HOTSPOT, которая вызывает подпрограмму финализации JAVA, так что если объект или класс не должны быть удалены, то подпрограмма финализации JAVA не вызывается. Для того чтобы принять такую схему, термин "подпрограмма финализации" следует понимать как включающий в себя и подпрограмму финализации JAVA, и "комбинацию" подпрограммы финализации JAVA и фрагментов кодаLINUX или HOTSPOT, которые вызывают или инициируют подпрограмму финализации JAVA. Вышеупомянутый вариант, в котором модифицируется код подпрограммы синхронизации JAVA,основан на предположении, что или система исполнения (например, JAVA HOTSPOT VIRTUAL MACHINE, написанная на С или JAVA), или операционная система (LINUX, написанная на С и Ассемблер,например) каждой из машин М 1Mn будет нормальным образом получать блокиратор на локальной машине (скажем, М 2), но не на любой другой машине (M1, M3, , Mn). Можно не изменять подпрограмму синхронизации JAVA, а вместо этого изменить подпрограмму LINUX или HOTSPOT, которая получает блокиратор локально, так что, соответственно, она также получает блокиратор на всех других машинах. Для того чтобы принять такую схему, термин "подпрограмма синхронизации" следует понимать как включающий в себя и подпрограмму синхронизации JAVA, и "комбинацию" подпрограммы синхронизации JAVA и фрагментов кода LINUX или HOTSPOT, которые выполняют получение и освобождение блокиратора. Термины объект и класс, используемые в данном изобретении, взяты из среды JAVA, и подразумевается, что они включают в себя схожие термины, взятые из других сред, например, динамически компонуемые библиотеки (dynamically linked libraries = DLL), или пакеты объектного кода, или функциональный узел, или адреса памяти. Используемый в изобретении термин "содержащий" (и его грамматические эквиваленты) должен пониматься в инклюзивном смысле "вхождения" или "включения", но не в эксклюзивном смысле как"состоящий только из". Уведомление об авторских правах Это изобретение содержит материалы, которые являются субъектом охраны авторских прав. Владелец авторских прав (являющийся заявителем) не имеет возражений против публикации данного изобретения или связанных с ним материалов патентным ведомством с целью обзора или рассмотрения, однако во всем остальном сохраняет все авторские права за собой. В частности, разнообразные команды нельзя вводить в компьютер без специального письменного разрешения данного владельца авторских прав.