KR101209023B1 - 코디네이트된 오브젝트를 갖는 변경 컴퓨터 아키텍쳐 - Google Patents

Abstract

본 발명은, 하나의 응용 프로그램(50)을 복수의 컴퓨터들(M1, . . . Mn)에서 동시에 동작되게 할 수 있는 하나의 변경 컴퓨터 아키텍쳐(50, 71, 72)를 개시한다. 각 컴퓨터의 공유 메모리(shared memory)는, 모든 메모리 판독 요청들이 국부적으로(locally) 만족되도록 수정(amendments) 및/또는 겹쳐쓰기(overwrite)로 업데이트된다. 초기 프로그램 로딩((75) 동안에 또는 이와 유사하게, 메모리로 하여금 재기록되거나 조작되게 하는, 명령어들이 식별된다(92). 모든 컴퓨터들에서 동등한 메모리 위치들이 업데이트되도록 하기 위해, 부가 명령어들이 삽입된다(103). 또한, 모든 컴퓨터에 대한 모든 메모리 위치가 동일한 방식으로 초기화되는, JAVA 언어 클래스 및 오브젝트의 초기화가 개시된다(162, 163). 종결이 오직, 모든 컴퓨터에 존재하는 마지막 클래스 또는 오브젝트가 더 이상 필요하지 않을 때, 일어나는, JAVA 언어 클래스들 및 오브젝트들의 종결이 또한 개시되어 있다(162, 163). 초기 프로그램 로딩(75)동안 또는 이와 유사하게, 응용 프로그램(50)이 하나의 특정 애셋(50A, 50X-50Y)상에 하나의 로크를 획득(또는 해제)하는 결과를 가져오는 명령어들이 식별된다. 모든 컴퓨터들이 업데이트되는 하나의 변경 동기화 루틴을 가져오도록 부가 명령어들이 삽입된다(162,163).

Description

코디네이트된 오브젝트를 갖는 변경 컴퓨터 아키텍쳐{Modified computer architecture with coordinated objects}

본 발명은 컴퓨터, 특히, 통신 네트워크를 통해 상호연결된 복수의 컴퓨터들에서 응용 프로그램의 동시 동작(operation)을 가능하게 하는 변경 컴퓨터 아키텍쳐(modified machine architecture)에 관한 것이다.

컴퓨터와 컴퓨팅(computing)의 출현이래, 컴퓨터용 소프트웨어는 하나의 단일 컴퓨터(single machine)에서 동작되도록 기억장치에 기록되어 왔다(written). 도 1에 나타낸 바와 같이, 종래의 단일 컴퓨터(1)는, 하나의 버스(bus)(4)를 통해 하나의 메모리(3)에 연결된 하나의 중앙 처리 장치(central processing unit 또는 CPU)(2)로 만들어진다. 스크린(5), 키보드(6) 및 마우스(7)와 같은 단일 컴퓨터(1)의 여러 다른 기능 유닛들(functional units)도 마찬가지로 버스(4)에 연결된다.

컴퓨터(1)의 성능에 대한 기본적인 제한은 CPU(2)에 의해 조작될(manipulated) 데이터와, 그 조작(manipulations)의 결과가 버스(4)에 의해 이동되어야(moved) 한다는 것이다. 버스(4)는, 버스에 액세스하고자 하는 장치들에 의해 형성된 소위 버 스 "대기열(queues)", 콘텐션(contention) 문제 등을 포함하는 다수의 문제들을 가진다. 이 문제들은, 어느 정도까지, 캐시 메모리(cache memory)를 포함하는 다양한 전략(stratagems)에 의해 완화될 수 있으나, 그러한 전략은 컴퓨터(1)의 관리비용(administrative overhead)을 반드시 증가시킨다.

수년에 걸쳐 컴퓨터 성능을 향상시키기 위해 다양한 시도들이 행해진 것은 당연하다. 하나의 접근법(approach)이 대칭형 다중 프로세서들(symmetric multiple processors)을 사용하는 것이다. 이 종래 기술은 소위 "슈퍼" 컴퓨터들에서 사용되어 왔으며, 도 2에 개략적으로 도시되어 있다. 여기서 복수의 CPU들(12)이 글로벌 메모리(global memory)(13)에 연결된다. 반면에 병목현상(bottleneck)이 CPU들(12)과 메모리(13) 사이의 통신에서 발생한다. 이 프로세스(process)는 "단일 시스템 이미지"로 불리어 왔다. 글로벌 메모리 전반에 걸쳐 분배되는 응용 프로그램(application)을 위한 메모리의 하나의 완전한 카피와 단 하나의 응용 프로그램만이 있다. 이 단일 응용 프로그램(single application)은 여하한 메모리 위치(memory location)로부터도 판독하고, 또 그 위치에 기록될 수 있다[즉, 공유(share)].

네트워크를 통해 상호연결된 복수의 그러한 컴퓨터들이 있는 경우, 단일 컴퓨터를 위해 기록된 단일 응용 프로그램을 취하고, 필요한 메모리 소스들을 부분들로 나누어서(in parts) 분배함으로써 이것이 달성된다. 그 다음에 이 부분들은, 모든 CPU들(12)에 의해 액세스가능한 글로벌 메모리(13)를 형성하기 위하여 복수의 컴퓨터들에 걸쳐서 분배된다. 이 프로시저(procedure)는 마스킹(masking), 또는 하이 딩(hiding), 단일 동작 응용 프로그램으로부터의 메모리 분배(memory partition)에 좌우된다. 하나의 컴퓨터상의 하나의 CPU가 다른 컴퓨터에 물리적으로 위치된 하나의 메모리 위치에 (네트워크를 통해) 액세스해야만 할 때 그 성능이 떨어진다.

슈퍼 컴퓨터들이 빠른 계산 속도(computational rates)를 달성하는데 있어 기술적으로 성공적이었기는 하나, 그 고유의 복잡성(complexity)이 그 제조 뿐 아니라 관리까지도 매우 비용이 많이 소요된다는 점에서 상업적으로는 성공적이지 않다. 특히, 단일 시스템 이미지 개념(concept)은 일용품(또는 대량 생산) 컴퓨터들과 네트워크를 넘어설 수 없다. 특히, 단일 시스템 이미지 개념은, 매우 빠른 (그리고 값비싼) 네크워크에 의해 상호연결된 매우 빠른 (그리고 이에 따라 매우 값비싼) 컴퓨터들에서 실제 응용되어 왔을 뿐이다.

복수의 컴퓨터들의 사용을 통한 증가된 컴퓨터 파워의 또 다른 가능성은, 도 3에 개략적으로 도시된 분배 컴퓨팅(distributed computing)이라는 선행기술 개념으로부터 발생한다. 이 공지된 장치(arrangement)에서, 단일 응용 프로그램(AP)은 도 3에서 n이 정수 3인 세 개의 컴퓨터에서 동작하도록, 그 저작자(또는 그 응용 프로그램과 친숙하게 된 다른 프로그래머)에 의해 여러 분리된 태스크(discrete tasks)로 분배된다. 여기서 컴퓨터(M1...M3)의 각각은 전체 응용 프로그램의 상이한 3분의 1을 동작시키고, 여러 컴퓨터에 가해진 로드(loads)는 대략적으로 동일한 것이다. 컴퓨터들은, 하나의 통신 링크, 인터넷, 인트라넷(intranets), 근거리 네트워크(local area networks) 등과 같은 여러 형태로 제공될 수 있는 네트워크(14)를 통해 통신한다. 그러한 네트워크(14)의 동작의 속도(speed)는 개별적인 컴퓨터 들(M1, M2 등)의 각각에서의 버스(4)의 동작 속도보다 더 느린 정도의 크기인 것이 일반적이다.

분배 컴퓨팅(Distributed computing)은 여러 단점들로 손상된다. 첫째, 응용 프로그램을 분배하는 것은 어려운 일이며, 이것은 수동으로 행해져야만 한다. 둘째, 네트워크(14) 전반에 걸친 데이터, 일부 결과, 결과 등의 통신은 관리 비용(administrative overhead)이다. 셋째, 예를 들어 3개로 분배된 응용 프로그램은 4개의 컴퓨터에서 잘 동작하지 않기 때문에, 이러한 분배의 필요성으로 인해 더 많은 컴퓨터를 사용함으로써 용량을 높이는데(scale upwardly) 매우 큰 어려움이 있다. 넷째, 컴퓨터들중 하나가 고장났을 경우, 전체 시스템의 전체 성능이 상당히 떨어진다.

종래의 또 다른 장치는, 도 4에 개략적으로 도시된 바와 같은 "클러스터(clusters)"를 통한 네트워크 컴퓨팅으로 알려져 있다. 이 접근법에서, 전체 응용 프로그램은 각각의 컴퓨터들(M1, M2 . . . Mn)에 로딩된다. 각 컴퓨터는 공통 데이터베이스(common database)와 통신하기는 하나 다른 컴퓨터와 직접 통신하지는 않는다. 각 컴퓨터가 동일한 응용 프로그램을 동작시키기는 하나, 각 컴퓨터는 상이한 "작업(job)"을 하고 그 자신의 메모리만을 사용한다. 이것은 각각이 공중에게 열차표를 판매하는 복수의 창구들과 다소 비슷하다. 이 접근법은 동작하고, 확장가능하고(scalable), 네트워크를 관리하기 어렵다는 단점이 주로 문제된다.

자바(JAVA)와 마이크로소프트.넷(MICROSOFT.NET)과 같은 컴퓨터 언어에는, 프로그래머들이 다루는 두가지 주된 유형의 구성(constructs)이 있다. 이들은 JAVA 언어에서, 이들은 오브젝트와 클래스(classes)로 알려져 있다. 하나의 오브젝트가 만들어질 때마다, "<init>"로 알려진 초기화 루틴 런(initialization routine run)이 있다. 이와 유사하게, 하나의 클래스가 로딩될 때마다, "<clinit>"로 알려진 초기화 루틴이 있다. 다른 언어들은 상이한 용어를 사용하나 유사한 컨셉(concept)을 이용한다.

그러나, 일단 하나의 오브젝트나 클래스가 더 이상 필요하지 않을 경우, 그것을 삭제하기 위하여 동등한 "클린 업(clean up)" 또는 삭제(deletion) 루틴은 없다. 그 대신, 이 "클린 업"은 배경 모드(background mode)에서 조심스럽게 발생한다.

또한, 어떤 컴퓨터 환경에서든지, 응용 프로그램의 상이한 부분들이 한번에 동일한 소스를 사용하려고 하는 것을 피하기 위해 그러한 애셋(assets), 리소스(resources) 또는 아키텍쳐(structures)의 사용을 가능하게 하는 하나의 로크(lock)를 획득하는 것이 필요하다. JAVA 환경에서 이것은 "동기화(synchronization)"로 알려져 있다. 이것은 JAVA에서 "모니터 엔터(monitor enter)" 및 "모니터 엑시트(monitor exit)" 명령어(instructions) 또는 루틴에 의해 달성된다. 다른 언어들은 상이한 용어를 사용하나 동일한 컨셉을 이용한다.

본 발명은, 하나의 응용 프로그램이 복수의 컴퓨터들에서 동시에 동작하는 컴퓨팅 환경을 개시한다. 그러한 환경에서 상술한 초기화, 클린 업 및 동기화 단계들이 모든 컴퓨터에 걸쳐 일관된 코디네이트된 방식으로(in a consistent and coordinated fashion) 동작하도록 할 필요가 있다. 본 발명의 발상인 코디네이션(coordination)이 본 발명의 목표이다.

본 발명의 제1 측면에 따라, 하나의 단일 컴퓨터에서만 동작하도록 각기 기록되어(written) 있기는 하지만 하나의 통신 네트워크에 의해 상호연결된 복수의 컴퓨터에서 동시에 동작하는 적어도 하나의 응용 프로그램을 갖는, 다중 컴퓨터 시스템이 개시되는데, 이 다중 컴퓨터 시스템에서는, 상기 응용 프로그램(들)의 상이한 부분들이 상기 컴퓨터들의 서로 다른 것들에서 대체로 동시에 실행하고, 상응하는 컴퓨터에서 각각 그리고 각기 대체로 동일한 네임(name)을 갖는, 같은 복수의 대체로 동일한 오브젝트들이 상기 각 부분에 대해 만들어지며; 상기 동일하게 명명된 각 오브젝트의 시초 콘텐츠(initial contents)가 대체로 동일하며; 상기 복수의 컴퓨터들이 각각 더 이상 그 해당 오브젝트를 참조할 필요가 없을 때 상기 동일한 오브젝트들이 모두 집합적으로(collectively) 삭제되고; 그리고 상기 다중 컴퓨터 시스템은, 어느 컴퓨터가 하나의 명명된 오브젝트를 사용하고자 할 경우, 그러한 오브젝트 사용을 허락하고 다른 모든 컴퓨터들은 그러한 사용 허락이 포기될 때까지 해당 명명 오브젝트를 사용하는 것을 금지하는 허가 로크(authorizing lock)를 얻도록 하는 로크 수단을 상기 모든 컴퓨터들에게 적용가능하게 포함한다.

본 발명의 제2 측면에 따라, 하나의 단일 컴퓨터에서만 동작하도록 각기 기록된 적어도 하나의 응용 프로그램을, 하나의 통신 네트워크에 의해 상호연결된 복수의 컴퓨터들에서 동시에 동작시키는 방법이 개시되는데, 이 방법은,
(i) 상기 컴퓨터들의 상이한 것들에서 상기 응용 프로그램(들)의 상이한 부분들을 실행하고, 상응하는 컴퓨터에서 각각 그리고 각기 하나의 대체로 동일한 네임을 가지는, 같은 복수의 대체로 동일한 오브젝트들을 상기 각 부분에 대해 만드는 단계와,

삭제

(ii) 상기 동일하게 명명된 각 오브젝트의 시초 콘텐츠(initial contents)를 대체로 동일하게 만드는 단계와,

(iii) 상기 복수의 컴퓨터들이 모두 더 이상 그 해당 오브젝트를 참조할 필요가 없을 때 상기 모든 동일한 오브젝트들을 집합적으로(collectively) 삭제하는 단계와, 그리고

(iv) 하나의 명명된 오브젝트를 사용하고자 하는, 상기 컴퓨터들 중 어느 것에 대해서든, 그러한 오브젝트 사용을 허락하고 다른 모든 컴퓨터들은 그러한 사용 허락이 포기될 때까지 해당 명명 오브젝트를 사용하는 것을 금지하는 허가 로크를 획득하도록 하는 단계를 포함하여 구성된다.

본 발명의 제3 측면에 따라, 하나의 저장 매체에 저장된 한 세트의 프로그램 명령어(program instructions)를 포함하여 구성되고, 복수의 컴퓨터들로 하여금 상술한 방법을 수행하게 허락하도록 동작할 수 있는, 컴퓨터 프로그램 제품이 개시되어 있다.

이제부터 본 발명의 실시예들을 도면둘을 참조하여 설명하기로 하는 바, 도면들 중

도 1은, 종래 컴퓨터의 내부 아키텍쳐(internal architecture)의 개략도이고,

도 2는, 공지된 대칭형 다중 프로세서의 내부 아키텍쳐를 나타낸 개략도이며,

도 3은, 종래의 분배 컴퓨팅(distributed computing)의 개략도이고,

도 4는, 클러스터를 사용하는 종래의 네트워크 컴퓨팅의 개략도이며,

도 5는, 본 발명의 제1 실시예에 따라 동일한 응용 프로그램을 동작시키는 복수의 컴퓨터들의 개략적인 블록도이고,

도 6은, JAVA 코드를 동작시키고 그에 따라 JAVA 가상 머신(JAVA virtual machine)을 구성하도록 구성된(arranged) 종래의 컴퓨터의 개략도이며,

도 7은, 도 6과 유사하나, 바람직한 실시예에 따라 코드의 초기 로딩(initial loading of code)을 설명하는 도면이고,

도 8은, 도 5와 유사하나, 도 7에 도시된 방식으로 JAVA 코드를 각기 동작시키는 복수의 컴퓨터들의 상호연결을 도시한 도면이며,

도 9는, 네트워크내의 각 컴퓨터에 동일한 응용 프로그램을 로딩하는 동안에 뒤따르는 단계들의 흐름도이고,

도 10은, 도 9와 유사한, 변경 프로시저를 나타낸 흐름도이며,

도 11은, 제1 실시예의 메모리 업데이팅을 이용하여 도 8의 컴퓨터에 수행된 다중 스레드 프로세싱(multiple thread processing)의 개략도이고,

도 12는, 도 11과 유사하나 다른 실시예를 도시한 개략도이며,

도 13은, 도 8의 컴퓨터에 대한 다중-스레드 메모리 업데이팅(multi-thread memory updating)을 나타낸 도면이고,

도 14는, JAVA 코드를 동작시키고 이에 따라 JAVA 가상 머신을 구성하도록 구성된 종래 컴퓨터의 개략도이며,

도 15는, 응용 프로그램을 동작시키고 하나의 부가 서버 컴퓨터(X)에 의해 서 비스되는 n개의 컴퓨터들의 개략도이고,

도 16은, 초기화 루틴의 변경(modification)을 도시한 흐름도이며,

도 17은, 초기화 루틴의 계속 또는 중단(abortion)을 도시한 흐름도이고,

도 18은, 서버 컴퓨터(X)으로 보내진 질문(enquiry)을 도시한 흐름도이며,

도 19는, 도 18의 요청에 대한 서버 컴퓨터(X)의 답변의 흐름도이고,

도 20은, "<clinit>" 명령에 대한 하나의 변경된 초기화 루틴을 나타낸 흐름도이고,

도 21은, "<init>" 명령에 대한 하나의 변경된 초기화 루틴을 나타낸 흐름도이며,

도 22는, 클린 업 또는 종결(finalization) 루틴의 변경을 나타낸 흐름도이고,

도 23은, 종결 루틴의 계속 또는 중단을 나타낸 흐름도이며,

도 24는, 서버 컴퓨터(X)로 보내진 질문을 도시한 흐름도이고,

도 25는, 도 24의 요청에 대한 서버 컴퓨터(X)의 답변의 흐름도이며,

도 26은, 모니터 엔터 및 엑시트 루틴의 변경을 나타낸 흐름도이고,

도 27은, 하나의 로크의 획득을 요청하는 컴퓨터의 프로세싱이 뒤따르는 프로세스를 도시한 흐름도이며,

도 28은, 하나의 로크의 해제 요청을 도시한 흐름도이고,

도 29는, 도 27의 요청에 대한 서버 컴퓨터(X)의 답변을 도시한 흐름도이며,

도 30은, 도 28의 요청에 대한 서버 컴퓨터(X)의 답변을 도시한 흐름도이고,

도 31은, 단일 컴퓨터에서 동작하는 2개의 응용 프로그램들을 구비하여, 복수 의 응용 프로그램을 동시에 가동시키기 위해 상호연결된 두 개의 랩탑 컴퓨터들(laptop computers)을 나타낸 개략도이며,

도 32는, 도 31과 유사하나, 각 컴퓨터에서 동작하는 하나의 응용 프로그램을 구비한 도 31의 장치를 나타낸 도면이고, 그리고

도 33은, 도 31 및 32와 유사하나, 두 컴퓨터들에서 동시에 동작하는 두 개의 응용 프로그램을 구비한 도 31의 장치를 나타낸 도면이다.

본 명세서는, 설명된 실시예들의 여러 가지 측면들을 실행하는 실제 프로그램 프래그먼트들(program fragments)을 제공하는, 부록 A, B, C 및 D를 포함한다. 부록 A는 필드(fields)에 관한 것이고, 부록 B는 초기화에 관한 것이다. 부록 C는 종결에 관한 것이다. 부록 D는 동기화에 관한 것이다.

도 5와 관련하여, 본 발명의 바람직한 실시예에 따라, 네트워크를 통해 통신하는 복수의 컴퓨터들(M1, M2 . . . Mn)에서 하나의 단일 응용 프로그램(50)이 동시에 동작될 수 있다. 아래에서 명백하게 될 바와 같이, 각 컴퓨터(M1, M2 . . . Mn)은 각 컴퓨터마다 동일한 응용 프로그램(50)으로 동작하고 따라서, 컴퓨터들(M1, M2 . . . Mn)은 동일한 응용 프로그램 코드와 데이터(50)를 가진다. 이와 유사하게, 각 컴퓨터(M1, M2 . . . Mn)은 동일한 (또는 대체로 동일한) 변경자(modifier)(51)로 동작하고 이에 따라 모든 컴퓨터들(M1, M2 . . . Mn)은, 컴퓨터(M2)의 변경자가 51/2로 표시되는 동일한(또는 대체로 동일한) 변경자(51)를 갖 는다. 또한, 각 컴퓨터(M1, M2 . . . Mn)에서의 응용 프로그램(50)의 로딩 동안에 또는 그 실행 전에, 각 응용 프로그램(50)은 동일한 룰[또는 최소한의 최적화 변화(minor optimising changes)가 각 변경자(51/1 . . . 51/n)내에서 허용되기 때문에 대체로 동일한 룰]에 따라 해당 변경자(51)에 의해 변경되어 왔다.

상술한 구성(arrangement) 때문에, 각 컴퓨터(M1, M2 . . . Mn)가 예를 들어 10MB의 공유(shared) 메모리 용량을 가지면, 그때는 각 응용 프로그램(5)이 사용할 수 있는 전체 공유 메모리가, 일반적으로 예상할 수도 있듯이, 10n MB가 아니라 단지 10MB일 뿐이다. 그러나, 이것이 어떻게 개선된 동작을 가져올 수 있는지 아래에서 명백하게 될 것이다. 각 컴퓨터(M1, M2 . . . Mn)이 하나의 비공유 메모리 용량을 가지는 것은 당연하다. 컴퓨터들(M1, M2 . . . Mn)의 비공유 메모리 용량은 대략 동일한 것이 일반적이나, 반드시 그럴 필요는 없다.

도 6에 개략적으로 도시된 바와 같이, 하나의 가상 머신을 만듦으로써 응용 프로그램의 특정 언어로 [여러 제조업자들 중의 하나에 의해 제조되고, 여러가지 상이한 언어들 중의 하나로 동작하는 하나의 운영체계(operating system)를 가지는] 하나의 컴퓨터를 동작시키는 것이 종래기술로 공지되어 있다. 도 6의 종래 장치는 JAVA 언어로 기록되고 JAVA 가상 머신(61)내에서 실행하는 응용 프로그램(50)의 형태를 취한다. 따라서, 응용 프로그램에서 사용이 계획된 언어(intended language)가 JAVA이면, 컴퓨터 제조업자들과 컴퓨터의 내부 디테일(internal details)과 상관없이 JAVA에서 코드를 동작시킬 수 있는 JAVA 가상 머신이 만들어진다. 더 상세한 것은 미국, 선 마이크로시스템즈 아이엔씨.(Sun Microsystems Inc.)의 티. 린드 홀름(T. Lindholm) 및 에프. 엘린(F. Yellin)이 저술한 "The JAVA Virtual Machine Specification" 2판을 참조하면 된다.

도 6의 잘 알려진 종래 구성은, 본 발명의 바람직한 실시예에 따라 도 7에 나타낸 바와 같은 "분배 실행 시간(distributed run time)" 또는 DRT(71)로 편하게 불리우는 하나의 부가적인 훠씰리티(facility)에 의해 변경된다. 도 7에서, 응용 프로그램(50)은 화살표(75)로 표시된 로딩 프로시저를 거쳐 분배 실행 시간 시스템(distributed runtime system)(71)을 통해 JAVA 가상 머신(72)에 로딩된다. 분배 실행 시간 시스템은, 분배 컴퓨팅 환경(Distributed Computing Environment; DCE)이라는 이름하에 개방 소프트웨어 재단(Open Software Foundation)으로부터 입수가능하다. 특히, 분배 가동시간(71)은, JAVA 가상 머신(72)을 초기에 만들기 위해, 화살표(75)로 표시된 JAVA 응용 프로그램(50)의 로딩 프로시저동안에 동작에 들어간다. 로딩 동안의 동작의 시퀀스(sequence)는 도 9와 관련하여 지금부터 설명하기로 한다.

도 8은, 각기 도 7에 도시된 JAVA 가상 머신들을 사용하는 도 5의 장치의 변경된 형태를 나타낸다. 동일한 응용 프로그램(50)이 각 컴퓨터(M1, M2 . . . Mn)로 로딩되는 것이 명백할 것이다. 그러나, 컴퓨터 하드웨어를 통해 물리적으로 루트(route)되기는 하지만, 각 컴퓨터(M1, M2 . . . Mn) 사이의 그리고 화살표(83)로 표시된 통신은, 각 컴퓨터내에서 개별적인 DRT들(71/1 . . . 71/n)에 의해 제어된다. 따라서, 이것은 실제적으로 컴퓨터들(M1, M2 . . . Mn) 자신들이 아닌 네트워크(73)를 통해 서로 통신하는 DRT들(71/1 . . 71/n)로서 개념화될 (conceptionalized) 수 있을 것이다.

이제 도 7과 도 9를 참조하면, 각 JAVA 가상 머신(72)을 만들기 위해 로딩된 프로그램(50)이, 로딩 프로시저(75) 동안 변경된다. 이 변경은 도 9의 단계(90)에서 시작하고, 로딩된 응용 프로그램(50)내의 모든 메모리 위치들[JAVA에서 필드로 불리우나, 동등한 용어가 다른 언어에서 사용됨]을 검출하는 초기 단계(91)를 포함한다. 그러한 메모리 위치는 단계(92)와 단계(93)에서의 뒤이은 프로세싱을 위해 식별될(identified) 필요가 있다. 로딩 프로시저(75) 동안에 DRT(71)는 이렇게 식별된 모든 메모리 위치들의 목록를 만들고, JAVA 필드는 오브젝트와 클래스에 의해 열거된다(listed). 휘발성 및 동기성 필드(volatile and synchronous fields)가 둘다 열거된다.

변경 프로시저의 다음 단계(phase)(도 9에 92로 표시됨)는, 단계(91)에 발생된 목록에 해당하는 필드 값들을 조작하거나 변화시키고, 이에 따라 해당 메모리 위치에서의 값이 변화되도록 필드에 기록하는 모든 프로세싱 활동(processing activity)의 위치 확인을 위해 실행가능 응용 프로그램 코드를 통해 탐색하는(search) 것이다. 필드값을 변화시키는 그러한 동작[일반적으로 JAVA 언어에서, putstatic 또는 putfield 가 검출되면, 필드값이 변화되었음을 다른 모든 컴퓨터들이 알 수 있도록, 업데이팅 전파 루틴(updating propagation routine)이 단계(93)에 의해 프로그램의 이 장소에 삽입된다. 그 후에, 도 9에 단계(94)로 표시된 일반적인 방식으로 로딩 프로시저가 계속된다.

로딩 동안의 초기 변경의 다른 형태가 도 10에 도시되어 있다. 도 10에서 시작 및 리스팅 단계(90 및 91)와 탐색 단계(92)는 도 9에서와 동일하다. 그러나, 프로세싱 스레드가 업데이팅을 수행하는 단계(93)에서와 같이, "업데이팅 전파 루틴(updating propagation routine)"을 삽입하기 보다는, 대신 "얼러트 루틴(alert routine)"을 단계(103)에서 삽입한다. "얼러트 루틴"은, 프로세싱에 사용되지 않고 DRT에 할당된 하나의 스레드(thread) 또는 스레드들에게 필요한 전파를 수행하도록 명령한다. 이 단계(103)는 낮은 오버헤드(overhead)를 가져오는, 더 유리한 대안(quicker alternative)이다.

로딩 프로시저 동안에 이 초기 변경이 발생하면, 도 11 및 12에 도시된 다중 스레드 프로세싱 동작들중의 어느 하나가 발생한다. 도 11에 나타낸 바와 같이, 스레드(111/1 . . . 111/4)로 구성되는 컴퓨터에서의 다중 스레드 프로세싱(110)이 발생하고, (이 실시예에서) 제2 스레드(111/2)의 프로세싱은 스레드(111/2)가 단계(113)에서 필드값의 변화를 알게 되는 결과를 낳는다. 이 단계에서, 그 스레드(111/2)의 통상의 프로세싱이 단계(114)에서 정지되고, 동일한 스레드(111/2)는 다른 모든 컴퓨터들(M2 . . . Mn)에게 네트워크(53)를 통해 단계(113)에서 발생된 변화된 값과 변화된 필드의 아이덴티티를 통지한다. 통신 프로시저의 끝에서, 스레드(111/2)는 그 다음에 단계(115)에서 필드값의 변화가 있는 다음 인스턴스(the next instance)까지 프로세싱을 다시 시작한다.

도 12에 도시된 다른 구성에서, 일단 스레드(121/2)가 단계(113)에서 필드값의 변화를 알게 되면, 그것은 [단계(125)와 화살표(127)로 표시한 바와 같이] DRT 프로세싱(120)으로 하여금 DRT 프로세싱(120)에 할당된 다른 스레드(들)(121/1)가 다 른 모든 컴퓨터들(M2 . . . Mn)에게 네트워크(53)를 통해 단계(128)에 따라 단계(113)에서 검출된, 변화된 필드와 변화된 값의 아이덴티티를 전파하도록 명령한다. 이것은 신속히 수행될 수 있는 동작이며, 따라서 초기 스레드(111/2)의 프로세싱은, 스레드(111/2)가 단계(115)에서 프로세싱을 다시 시작하기 전에, 단계(125)에 표시된 바와 같이 잠깐동안만 중단된다. [화살표(127)에 의해 표시된 바와 같이] 변화를 통지받은 다른 스레드(121/1)는 그 다음에 네트워크(53)를 통해 단계(128)에서 표시된 변화를 다른 각 컴퓨터(M2 . . . Mn)로 전달한다.

도 12의 제2 구성은 [일반적으로, 동일한 요구에 처해지지 않는] 여러 스레드들(111/1, 111/3 및 121/1)의 프로세싱 파워를 더 잘 활용하게 하며, "n"[n은, 2이거나 2보다 더 큰, 네크워크(53)에 연결되고 응용 프로그램(5)을 동시에 동작시키는 컴퓨터들의 전체 수를 나타냄]의 크기를 증가시키는 더 우수한 확장성(scaling)을 부여한다. 사용된 구성에 상관없이, 변화된 필드 및 아이덴티티와 단계(113)에서 검출된 값은 네트워크상에서 다른 모든 컴퓨터들(M2 . . . Mn)로 전파된다.

이것은, 도 12의 DRT(71/1)와 그 스레드(121/1)[도 13에 단계(128)로 나타냄]가 네트워크(53)를 통해 아이덴티티와, 컴퓨터(M1)에서 프로세싱됨으로써 도 12의 단계(113)에서 발생되어 목록에 들어있는 메모리 위치의 변화된 값과 아이덴티티를 다른 컴퓨터들(M2 . . . Mn) 각각으로 보낸다.

다른 컴퓨터들(M2 . . . Mn) 각각은, 네트워크(53)로부터 아이덴티티와 값의 쌍(identity and value pair)을 수신하고 로컬(local) 상응 메모리 위치(local corresponding memory location)에 새로운 값을 기록함으로써, 컴퓨터(Mn)에 대해 도 13의 단계(135)와 단계(136)에 의해 표시된 동작을 수행한다.

분배 소프트웨어를 사용하는 도 3의 종래 구성에 있어서, 하나의 컴퓨터의 소프트웨어로부터 다른 컴퓨터에 물리적으로 위치된(physically located) 메모리로의 메모리 액세스는 컴퓨터들을 상호연결하는 네트워크에 의해 허가된다. 그러나, 그러한 메모리 액세스는 컴퓨터의 중앙 처리 장치의 약 10⁶ - 10⁷ 사이클의 프로세싱을 지연시킬 수 있다. 이것은 대부분 다중 상호연결 컴퓨터들의 성능의 감소의 원인이 된다.

그러나, 도 8과 관련하여 위에 설명한 본 발명의 장치에 있어서, 모든 필드의 현재 값(current value)이 메모리를 판독할 필요를 발생시키는 프로세싱을 수행하는 컴퓨터에 저장되기 때문에, 데이터의 모든 판독은 국부적으로(locally) 만족된다. 그러한 국부적 프로세싱은 중앙 처리 장치의 10² - 10³ 사이클내에서 만족될 수 있다. 따라서, 실제로, 판독을 포함하는 메모리 액세스에 대한 대기 시간은 없다.

그러나, 대부분의 응용 소프트웨어는 메모리를 자주 판독하나, 비교적 드물게 메모리에 기록한다. 그 결과로서, 메모리가 기록되거나 재기록되는 속도는 메모리가 판독되는 속도에 비해 비교적 느리다. 메모리의 기록 또는 재기록에 대한 이러한 느린 요구(slow demand) 때문에, 필드는 비싸지 않은 상용 네트워크(53)를 통해 비교적 느린 속도로 연속적으로 업데이트될 수 있기는 하지만, 이 느린 속도는 메모리에 기록하기 위한 응용 프로그램 요구에 부합하기에 충분하다. 도 8의 구성의 성능이 도 3의 것보다 크게 월등하다는 것이 그 결과이다.

상술한 것과 관련한 또 다른 변경에 있어서, 아이덴티티와 변화된 필드의 값은, 여러 컴퓨터들을 상호연결하는 네트워크(53)의 통신 속도에 대한 요구를 더 감소시키기 위해 배치들(batches)로 그룹화될 수 있다.

초기에 필드를 기록할 때 각 DRT(71)에 의해 만들어진 하나의 테이블에, 각 필드별로 네트워크 전반에 걸쳐 공통되고 네트워크가 인지하는(recognises) 하나의 네임 또는 아이덴티티가 있음이 당업자들에게 또한 명백할 것이다. 그러나, 각 컴퓨터가 그 자신의 내부 프로세스(internal processes)에 따라 상이한 위치에 변화된 필드 값을 점진적으로 저장할 것이기 때문에, 개별적인 컴퓨터에 있어서, 특정하게 명명된 필드(given named field)에 상응하는 메모리 위치가 시간이 흘러감에 따라 변화할 것이다. 따라서, DRT들 각각의 테이블은, 일반적으로, 상이한 메모리 위치들을 가질 것이나, 각 글로벌 "필드 네임(field name)"은 상이한 메모리 위치에 저장된 동일한 "필드값"을 가질 것이다.

로딩 동안에 응용 프로그램의 상술한 변경이 하기의 다섯까지의 방식으로 성취될 수 있다는 것이 이 분야에 통상의 지식을 가진 사람들에게 또한 명백할 것이다:

(i) 로딩에서의 재-컴파일(re-compilation),

(ii) 로딩에 앞선 전-컴파일 프로시저(pre-compilation procedure),

(iii) 로딩에 앞선 컴파일,

(iv) 저스트-인-타임 컴파일(just-in-time compilation), 또는

(v) 로딩 후 [그러나, 또는 예를 들어, 분배 환경(distributed environment)에서 관련 또는 해당 응용 코드(application code)의 실행전]의 재-컴파일.

전통적으로, 용어 "컴파일(compilation)"은, 예를 들어 소스에서 오브젝트 코드로 또는 하나의 언어로부터 다른 언어로의, 코드 또는 언어에 있어서의 변화를 의미한다(implies). 본 명세서에서 용어 "컴파일"( 및 그 문법적 동등어)의 사용은 그렇게 제한적이지 않으며, 동일한 코드 또는 언어내에서의 변경도 또한 포함할 수 있다.

제1 실시예에서, 특정한 컴퓨터, 즉 컴퓨터(M2)은 그 자신에 응용 코드를 로딩하고, 그것을 변경시키고, 그 다음에 다른 컴퓨터들(M1, M3, . . . Mn) 각각에 변경된 코드를 (연속적으로 또는 동시에) 로딩시킨다. "마스터/슬레이브(master/slave)"로 명명될 수 있는, 이 구성에서, 각 컴퓨터(M1, M3, . . . Mn)은 컴퓨터(M2)에 의해 주어진 것을 로딩한다.

다른 실시예에서, 각 컴퓨터는 응용 코드를 수신하나, 그것을 변경시키고, 그 컴퓨터에 변경 코드를 로딩한다. 이것은 그 아키텍쳐와 운영 체계(operating system)에 기초하여 다소 상이하게 최적화될 각 컴퓨터에 의해 변경이 수행되는 것을 가능하게 한다.

다른 구성에서, 특정 컴퓨터, 즉 컴퓨터(M1)는, 비변경(unmodified) 코드를 로딩하고, 다른 모든 컴퓨터들(M2, M3, . . . Mn)은 원 응용 코드(original application code)를 삭제하고 변경된 버전(modified version)을 로딩하기 위해 변경(modification)을 한다.

모든 인스턴스에서(in all instances), 공급은 분지되거나[즉, M2는 M1, M3, M4 등에 각각 직접 공급함] 직렬로 되거나(cascaded) 또는 연속적일[즉, M2는 M1에 공급하고, M1은 그 다음에 M3에 공급하고 M3는 그 다음에 M4에 공급하는 등] 수 있다.

다른 구성에서, 컴퓨터들(M1 내지 Mn)이 모든 로딩 요청(load requests)을 하나의 부가 컴퓨터(도시되지 않음)로 보낼 수 있고, 이 부가 컴퓨터는 응용 프로그램을 동작시키지 않고, 상술한 방법들중의 어떤 것에 의해 변경을 실행하고, 변경된 루틴을 컴퓨터들(M1 내지 Mn) 각각에 대해 되돌려보내며, 그 다음에 컴퓨터들(M1 내지 Mn)이 변경 루틴을 역내에(locally) 로딩한다. 이 구성에서, 컴퓨터들(M1 내지 Mn)은, 각 컴퓨터로 변경된 루틴을 되돌려보내는 이 부가 컴퓨터로 모든 로딩 요청을 보낸다. 이 부가 컴퓨터에 의해 수행된 변경은 본 발명의 범위하에 커버되는 여하한 변경들을 포함할 수 있다.

컴퓨팅 기술의 당업자들은 컴퓨터 코드에 변경을 만들어내는데 사용되는 적어도 4가지 기술들을 알 것이다. 첫 번째 것은 변경을 오리지널 (소스) 언어에 만드는 것이다. 두 번째 것은 (예를 들어 JAVA에) 오리지널 코드를 중간 표시(intermediate representation)[또는 중간 언어]로 변환시키는(convert) 것이다. 일단 이 변환(conversion)이 일어나면, 변경이 이루어지고, 그 다음에 변환이 반전된다(reversed). 이것은 변경 JAVA 코드(modified JAVA code)의 바람직한 결과를 제공한다.

세번째 가능성은 [직접적으로 또는 상술한 중간 언어를 통해] 컴퓨터 코드(machine code)로 변환하는 것이다. 그 다음에 컴퓨터 코드는, 로딩되고 실행되 기 전에, 변경된다. 네 번째 가능성은 오리지널 코드를, 하나의 중간 표시(intermediate representation)로 변환시키는 것인데, 그 중간 표시는 그 후에 변경되고 이어서 컴퓨터 코드로 변환된다.

본 발명은 4개의 모든 변경 루트들과 그리고 또한 그러한 루트들의 2, 3 또는 심지어 4 모두의 조합을 포함한다.

도 14를 이제 참조하면, JAVA 가상 머신으로서 동작되는 종래의 하나의 단일 컴퓨터를 개략적으로 도시되어 있다. 이런 식으로, [여러 제조업자들 중의 하나에 의해 제조되고 여러가지 상이한 언어들 중의 하나에서 동작하는 하나의 운영 체계를 가지는] 하나의 컴퓨터는 응용 프로그램(50)의 특정 언어, 이 인스턴스에서는 JAVA 언어로 동작할 수 있다. 즉, 하나의 JAVA 가상 머신(72)은 JAVA 언어로 코드(50)를 동작시킬 수 있고, 컴퓨터 제조업자와 컴퓨터의 내부 디테일(internal details)에 상관없이 JAVA 아키텍쳐를 이용할 수 있다.

JAVA 언어에서, 초기화 루틴 <clinit>은 특정 클래스 파일(50A)이 로딩될 때 한번만 발생한다. 그러나, 초기화 루틴 <init>은 종종, 예를 들어 새로운 오브젝트들(50X, 50Y 및 50Z)이 만들어질 때마다 발생한다. 또한, 하나의 단일 클래스(50A)와 세 개의 오브젝트들(50X-50Z)을 갖는, 도 14에 도시된 응용 프로그램에서, 클래스들이 오브젝트들에 앞서 로딩되도록, 제1 클래스(50A)가 먼저 로딩되고, 그 다음에 제1 오브젝트(50X)가 로딩되며, 그 다음에 제2 오브젝트(50Y)가 로딩되고 마지막으로 제3 오브젝트(50Z)가 로딩된다. 도 14에서와 같이, 하나의 단일 컴퓨터(72)만이 있는 경우, 로딩 프로시저 동안에 동작하도록 의도된 초기화 루틴의 동작에서 그 다음에 충돌(conflict)이나 불일치(inconsistency)가 발생하지 않는다.

그러나, 도 8[그리고 또한 도 31 내지 도 33]에 도시된 구성에서, 각기 하나의 통신 네트워크(53)를 통해 상호연결되고, 각기 하나의 변경자(modifier)(51)가 구비되며, 하나의 공통 응용 프로그램(50)이 로딩되는, 복수의 개별적인 컴퓨터들(M1, M2 . . . Mn)이 구비된다. 본질적으로 변경자(51)는 개별 컴퓨터들(M1, M2 . . Mn) 각각에 하나의 동일한 메모리 구조와 콘텐츠를 복제하기(replicate) 위한 것이다. 따라서, 그 결과, 그러한 컴퓨팅 환경에서 개별 컴퓨터들(M1, M2 . . Mn) 각각이 일관된 방식으로 초기화되도록 하는 것이 필요하다. 도 5의 변경자(51)의 변경 기능은 도 8의 DRT(71)에 의해 제공된다.

일관된 초기화를 확보하기 위해, 응용 프로그램(50)은 하나의 초기화 루틴을 특징짓는(define) 프로그램 단계들을 검출하기 위해 정밀하게 검사된다(scrutinized). 이 정밀 검사는 로딩에 앞서, 또는 로딩 프로시저(75) 동안에, 또는 심지어 로딩 프로시저(75) 후에 [그러나, 관련 해당 응용 코드의 실행 전에] 발생할 수 있다. 그것은, 용어 "컴파일"이 일반적으로 코드 또는 언어의 변화, 예를 들어 소스 코드로부터 오브젝트 코드로 또는 하나의 언어에서 다른 언어로의 변화를 포함하다는 조건으로 컴파일 프로시저(compilation procedure)에 비유될 수 있다. 그러나, 이 인스턴스에서(in the present instance) 용어 "컴파일" (및 그 문법적 등등어)은 그렇게 제한적이지 않으며, 또한 동일한 코드 또는 언어내에서의 변경을 포함할 수 있다.

그 결과로서, 상술한 정밀검사(scrutiny)에서, <clinit> 루틴을 처음에 찾다가 발견되면 하나의 변경된 <clinit> 루틴을 발생시키기 위해 하나의 변경 코드(일반적으로 수개의 명령어)가 삽입된다. 이 변경된 루틴은 클래스(50a)를 컴퓨터들중의 하나, 예를 들어 JVM#1에 로딩하고, 모든 다른 컴퓨터들(M2 . . . Mn)에게 그러한 클래스(50A)가 존재함과 그 현재 상태(its present state)를 알리게(tell) 되어 있다. 여러 가지 상이한 모드가 있고, 이에 따라 이 변경과 로딩이 수행될 수 있다.

따라서, 하나의 모드에서, 로딩 머신, 이 예에서는 JVM#1의 DRT(71)는, 제1 클래스(50A)가 이미 초기화되었으면, 모든 다른 컴퓨터들에 대하여 DRT들(71/2 . . . 71/n)을 요청한다. 이 질문에 대한 답변이 예(yes)이면, 그 때는 정규(normal) 초기화 프로시저가 무력화된다(is turned off or disabled). 만약 답변이 no 이면, 그 때는 정규 초기화 프로시저가 작동되고, 그러한 프로시저동안 생긴 그 결과로서의 변화가, 도 8에 화살표(83)로 표시된 바와 같이, 다른 모든 컴퓨터들로 전달된다.

하나의 오브젝트, 예를 들어 50X, 50Y 또는 50Z가 로딩되어야 하는 각 경우에 유사한 프로시저가 일어난다. DRT(71/1)가, 질문(interrogation)의 결과로서, 문제의 특정 오브젝트, 즉 오브젝트(50Y)가 이미 다른 컴퓨터들(M2 . . . Mn)에 로딩되었음을 식별하지(discern) 못한 경우, DRT(71/1)는 오브젝트 초기화 루틴을 동작시키고, 다른 컴퓨터들(M2 . . . Mn)의 각각에 [일반적으로 피어 오브젝트(peer object)로 명명될 수 있는] 하나의 동등한 오브젝트를 초기값들의 하나의 카피(copy)와 함께 로딩한다. 그러나, DRT(71/1)가 문제의 오브젝트(50Y)가 이미 다른 컴퓨터들에 존재하는 것을 결정하면(determine), 그 때는 일반적인 초기화 기능 이 디세이블되고(disabled) 하나의 로컬 카피가 현재 값의 카피와 함께 만들어진다. 게다가 또 원하는 결과를 일으킬 수 있는 여러 방법이 있다.

도 15에서 알 수 있듯이, 컴퓨터들(M1, M2 . . . Mn)이 전과 같이 존재하고, 동일한 응용 프로그램(또는 프로그램들)을 모든 컴퓨터들(M1, M2 . . . Mn)에서 동시에 동작시키는, 도 8의 일반적인 구성에 대한 변경이 제공된다. 그러나, 종전의 구성은, 하나의 하우스키핑 기능, 그리고 특별히 초기화, 클린 업(clean up) 및/또는 구조, 애셋 및 리소스의 동기화 기능을 편리하게 공급할 수 있는 하나의 서버 컴퓨터(server machine)(X)의 제공에 의해 변경된다. 그러한 서버 컴퓨터(X)는 그 컴퓨터계산 로드(computational load)가 낮기 때문에 PC와 같은 저가 상용 컴퓨터(low value commodity computer)도 무방하다. 도 15에 파선으로 나타낸 바와 같이, 두 개의 서버 컴퓨터들(X 및 X+1)이 시스템의 전체적인 신뢰도를 증가시키는 여분 구비의 목적들을 위해 제공될 수 있다. 그러한 두 개의 서버 컴퓨터들(X 및 X+1)이 구비되면, 하나의 클러스터에서 듀얼 컴퓨터(dual machines)로 동작되는 것이 바람직하다. 부가 컴퓨터(X+1)는 도 15에 파선으로 나타낸 바와 같이 임의적이다.

그 컴퓨터계산 로드가 컴퓨터들(M1, M2 . . . Mn) 전체에 분배될 수 있기 때문에, 서버 컴퓨터(X)를 구비하는 것이 필요하지 않다. 이와 달리, [마스터/슬레이브 형 동작에서] 하나의 컴퓨터에 의해 동작되는 데이터베이스가 하우스키핑 기능을 위해 사용될 수 있다.

도 16은 초기화를 위해 뒤따를 바람직한 일반 프로시저를 나타낸 것이다. 로딩 프로시저(161)가 시작된 후에, 실행되어야 할 명령어들이 차례차례로 고려되고, 모든 초기화 루틴들이 단계(162)에 나타낸 것처럼 검출된다. JAVA 언어에서 이들은 <init> 및 <clinit> 루틴[또는 JAVA 용어(terminology)로 메쏘드(methods)]이다. 다른 언어는 다른 용어를 사용한다.

초기화 루틴이 단계(162)에서 검출된 경우, 그것은 단계(163)에서, 일반적으로 추가적인(further) 명령어를 루틴에 삽입함으로써 변경된다. 이와 달리, 변경 명령어(modifying instructions)가 루틴에 앞서 삽입될 수 있다. 일단 변경 단계(163)가 완료되면, 단계(164)에 나타낸 바와 같이 로딩 프로시저가 계속된다.

도 17은 변경의 특정 형태를 도시한 것이다. 단계(171)에서 루틴을 시작한 후에, 초기화될 구조, 애셋 또는 리소스 [JAVA에서 클래스 또는 오브젝트로 불리움]가, 단계(172)에서 모든 컴퓨터들에 의해 광범위하게(globally) 사용될 수 있는 하나의 네임 또는 태그(tag)에 할당된다. 이것은 도 15의 서버 컴퓨터(X)에 의해 유지되는 하나의 테이블을 통해 가장 편리하게 행해진다. 이 테이블은 또한 초기화될 클래스 또는 오브젝트의 상태(status)를 포함한다.

도 17에 나타낸 바와 같이, 단계(173)과 단계(174)가 다른 곳에서[즉, 로딩을 수행하는 컴퓨터가 아닌 다른 컴퓨터에서] 글로벌 네임이 아직 초기화되지 않은 것을 결정하면, 이것은, 만들어져야 할 것은 첫 번째 오브젝트 또는 클래스이기 때문에, 오브젝트 또는 클래스가 단계(176)를 수행함으로써 일반적인 방식으로 초기화될 수 있음을 의미한다.

그러나, 단계(173)와 단계(174)가 글로벌 네임이 이미 다른 곳에서 이용되는 것을 결정하면, 이것은 다른 컴퓨터가 이미 이 클래스 또는 오브젝트를 초기화하였음을 의미한다. 그 결과로서, 정규 초기화 루틴은 단계(175)를 수행함으로써 완전히 중지된다.

도 18은 로딩 머신(M1, M2 . . . Mn 중의 하나)에 의해 만들어진 도 15의 서버 컴퓨터(X)에 대한 질문(enquiry)을 나타낸다. 단계(182)에 표시된 바와 같이, 컴퓨터(X)로부터 답변이 수신될 때까지, 단계(181)에 표시된 바와 같이 로딩 머신의 동작이 일시적으로 중단된다.

도 19는, 도 18의 단계(181)의 질문에 답하여 도 15의 컴퓨터(X)에 의해 수행된 활동(activity)을 나타낸 도면이다. 초기화 상태는 단계(192)와 단계(193)에서 결정되고, 만약 이미 초기화되었으면 그에 따른 답변이, 단계(194)를 수행함으로써, 질문 컴퓨터(enquiring machine)로 보내진다. 이와 유사하게, 만약 초기화 상태가 초기화되지 않으면, 이에 상응하는 답변이 단계(195)와 단계(196)을 수행함으로써 보내진다. 단계(182)에 의해 만들어진 질문 대기 컴퓨터(waiting enquiring machine)가 그 다음에 이에 따라 답변할 수 있다.

부록된 부록에 관하여 언급하면, 부록 중

부록 A1-A10은 필드와 관련된 실제 코드를 나타낸 것이고,

부록 B1은 미변경(unmodified) <clinit> 명령어의 일반적인 코드 프래그먼트(code fragment)이며,

부록 B2는 변경 <clinit> 명령어에 대한 동등어(equivalent)이고,

부록 B3는 미변경 <init> 명령어의 일반적인 코드 프래그먼트이며,

부록 B4는 변경 <init> 명령어에 대한 동등어이다.

또한, 부록 B5는 부록 B2의 코드에 대한 하나의 대안(alternative)이며, 부록 B6는 부록 B4의 코드에 대한 하나의 대안이다.

나아가, 부록 B7는, "초기화 서버"에게 관련 클래스 또는 오브젝트의 초기화 상태에 대해 질문하는 InitClient 의 소스-코드(source-code)이다.

부록 B8은, InitClient 에 의한 초기화 상태 질문을 수신하고 이에 대한 응답으로 이에 상응하는 상태를 되돌려보내는, InitServer의 소스-코드이다.

이와 유사하게, 부록 B9는 부록 B1-B6의 예시들의 전/후에 사용되는 예시 응용 프로그램(example application)의 소스-코드이다.

이제 도 20을 참조하면, 부록 B1의 코드 프래그먼트로부터 부록 B2의 코드 프래그먼트로 변환하기 위해 클래스와 관련된 <clinit> 루틴을 변경하기 위해 뒤따르는 프로시저가 나타나 있다. 응용 프로그램(50)의 JAVA 가상 머신(72)으로의 초기 로딩은 단계(201)에서 시작되고, 단계(202)를 수행함으로써 <clinit> 루틴을 나타내는 그러한 명령어들을 검출하기 위해 코드의 각 라인이 정밀검사된다. 그렇게 해서 일단 검출되면, <clinit> 루틴은 단계(203)를 수행함으로써 부록 B2에 나타낸 바와 같이 변경된다. 단계(204)에 의해 표시된 바와 같이, 변경이 완료된 후에 그 다음에 로딩 프로시저가 계속된다.

부록 B1과 부록 B2는 각각 <clinit> 명령어의 발췌(excerpt)의 전과 후이다. 메쏘드에 부가된 변경 코드는 굵게 강조하였다. 부록 B1의 오리지널 코드 샘플에서, <clinit> 메쏘드는 그 자신의 하나의 새로운 오브젝트를 만들고,"thisTest" 라 고 불리우는 메모리 위치(필드)에 이것을 기록한다. 따라서, 분배된 환경내의 클래스 로딩 관리없이, 각 컴퓨터는 동일한 공유 메모리 위치(필드)를, 상이한 오브젝트로, 재초기화시킬(reinitialize) 수 있다. 이것은, 로딩되는 응용 프로그램의 프로그래머가 일어날 것으로 예상한 것이 명백히 아니다.

그러므로, DRT를 이용하여, 응용 프로그램 코드는, 이것은 <clinit> 메쏘드를 변화시킴으로써 컴퓨터로 로딩되면서 변경된다. (굵게 강조된) 변화된 것들은, <clinit> 메쏘드가 실행하는 초기 명령어들이다. 이들 부가된 명령어들은, 이 클래스의 로딩 상태에 상응하여 true 또는 false 를 되돌려보내는, isAlreadyLoaded() 메쏘드를 콜링함(calling)으로써 이 클래스가 이미 로딩되었는지를 체크한다(check).

DRT의 isAlreadyLoaded() 메쏘드는, 이 클래스의 로딩 상태의 결정에 사용될, 이 클래스에 대한 하나의 독특한 식별자(unique identifier)(부록 B5 및 B6 참조), 예를 들어 이 클래스를 나타내는 클래스의 네임, 또는 클래스 오브젝트, 또는 모든 컴퓨터들에 걸쳐 이 클래스를 나타내는 독특한 수를 나타내는 인수(argument)를 선택적으로 취할 수 있다(argument). 이런 식으로, isAlreadyLoaded 테이블내의 정확한 기록을 조사하기(consult) 위해 각 클래스의 독특한 식별자를 사용함으로써 복수 클래스들중 어느 것이 이미 로딩되고, 어느 것이 로딩되지 않은 것인지에 대해 혼동함이 없이, DRT가 동시에 이중 클래스의 로딩을 지지할 수 있다.

DRT는 여러 방식으로 클래스의 로딩 상태를 결정할 수 있다. DRT는 각 컴퓨터에 차례로 이 클래스가 로딩되었는지를 질문할 수 있고, 어떤 컴퓨터가 true 라고 답변하면, 그 때는 true, 그렇지 않으면 false 라고 되돌려답변하는 것이 바람직하다. 이와 달리, 로컬 컴퓨터의 DRT는, 이 클래스가 로딩되었는지의 여부를 결정하기 위해, [아마도 하나의 별개 컴퓨터(예를 들어 컴퓨터 X)의] 하나의 공유 레코드 테이블, 또는 로컬 컴퓨터의 하나의 코히런트 공유 레코드 테이블(coherent shared record table) 또는 데이터베이스를 참조할 수 있다.

DRT가 false 라고 보내면, 이것은 이 클래스가 분배 환경에서 어떤 컴퓨터에도 이전에 로딩되지 않았음을 의미하며, 그러므로, 이 실행이 최초인 것으로(the first and original) 간주되어야 한다. 그 결과로서, 현재의 컴퓨터를 포함하는, 다른 모든 컴퓨터들에 대한 이어지는 isAlreadyLoaded의 모든 호출(invocations)이 true 로 답변되도록, DRT는 공유 레코드 테이블의 이 클래스에 대한 "isAlreadyLoaded" 레코드를 true 로 업데이트하여야 한다. 따라서, DRT.isAlreadyLoaded()이 false 를 보내면, 변경된 <clinit> 메쏘드는, 삽입된 세개의 명령어들을 추적하는(trail) 오리지널 코드 블록(original code block)을 계속한다.

반면에, DRT가 true 로 답변하면, 그 때는 이것은 이 클래스가, 로딩된 클래스의 공유 레코드 테이블에 기록된 대로, 분배 환경에 이미 로딩되었음을 의미한다. 그러한 경우에, 이미 초기화된 메모리 위치 등에 겹쳐쓸(overwrite) 것이기 때문에, 오리지널 코드 블록은 실행되어서는 아니된다. 따라서, DRT가 true 라고 답변하면, 삽입된 세 개의 명령어들이 오리지널 코드의 실행을 막고, 응용 프로그램으로 곧바로 돌아간다.

오브젝트들에 관한 <init> 루틴을 위한 동등한 프로시저가, 그 단계(212) 및 단계(213)가 도 20의 단계(202) 및 단계(203)와 같은 도 21에 도시되어 있다. 이것은, 부록 B3의 코드가 부록 B4의 코드로 변환되는 결과를 가져온다.

<clinit>에 대해 사용된 것과 유사한 변경이 <init>에 대해 사용된다. 응용 프로그램 <init> 블록 [또는 블록들(<clinit>와는 달리 복수일 수 있기 때문임)]은 단계(212)에 나타낸 바와 같이 검출되고, 분배 환경 전반에 걸쳐 일관되게 동작하기(behave coherently) 위해 단계(213)에 나타낸 바와 같이 변경된다.

부록 B3의 예에서, 응용 프로그램의 <init> 명령어는 하나의 메모리 위치(필드)를 로딩 시간의 타임스탬프(timestamp)로 초기화한다. 응용 프로그램은, 예를 들어 이 오브젝트가 만들어질 때 기록하기 위해 이것을 사용할 수 있다. 피어 오브젝트(peer objects)가 상이한 시간에 로딩될 수 있는 분배 환경에서, 첫번째로-로딩된 피어 오브젝트의 타임스탬프가 이후의 피어 오브젝트에 의해 겹쳐쓰기되지(overwritten) 않도록 확실하게 하기 위해 특별한 처리가 필요하다.

변경이 발생한 후에 해체된 명령어 시퀀스(disassembled instruction sequence)가 부록 B4에 제시되어 있고, 변경된/삽입된 명령어들이 굵게 강조되어 있다. <init> 변경을 위해, <clinit> 변경과는 달리, 변경 명령어들이 바로 맨 처음 대신에 "invokespecial" 명령어 다음에 놓여질 필요가 종종 있다. 이것에 대한 이유가 JAVA 가상 머신 명세(specification)에 의해 드라이브된다(driven). 다른 언어들은 종종 유사한 미묘한 디자인 뉘앙스(subtle designs nuances)를 가진다.

초기화가 이미 수행되었는지, 그리고 수행하지 않았는지, 그렇다면, 추가적 초 기화를 수행하지 않는지를 확인하는 것이 시험의 기본적인 컨셉이라 가정하면, 이 컨셉이 수행될 수 있는 여러 가지 상이한 방법들이 있다.

제1 실시예에서, 특정 컴퓨터, 예를 들어 컴퓨터(M2)는 클래스 또는 오브젝트를 그 자신에 로딩한 다음 다른 컴퓨터들(M1, M3 . . Mn) 각각을 (연속적으로 또는 동시에) 로딩한다. "마스터/슬레이브"로 명명될 수 있는 이 구성에서, 컴퓨터들(M1, M3 . . Mn) 각각은 컴퓨터(M2)에 의해 주어진 것을 로딩한다.

이 "마스터/슬레이브" 구성의 변종(variation)에서, 컴퓨터(M2)는 <clinit> 루틴을 변경되지 않은 형태로 컴퓨터(M2)에 로딩한 다음 클래스를 초기화 루틴을 완전히 삭제함으로써 변경시키고, 그 변경된 클래스를 다른 컴퓨터들에 로딩한다. 따라서, 이 인스턴스에서 변경은 초기화 루틴을 바이-패싱(by-passing) 하는 것이 아니라 하나를 제외한 모든 컴퓨터에서 그것을 삭제하는 것이다.

다른 실시예에서, 각 컴퓨터는 초기화 루틴을 수신하기는 하나 그것을 변경시키고, 변경된 루틴을 그 컴퓨터에 로딩한다. 이것은 각 컴퓨터에 의해 수행된 변경으로 하여금 다소 다르게 하며, 모든 다른 유사한 변경과 여전히 일관되게(coherent), 그 아키텍쳐와 운영 체계에 기초하여 최적화된다.

또 다른 구성에서, 특정 컴퓨터, 예를 들어 M1은 클래스를 로딩하고, 다른 모든 컴퓨터들(M1, M3 . . Mn)은 초기화 루틴을 삭제하고 변경된 버전을 로딩하기 위해 변경을 한다.

모든 인스턴스에서, 공급(supply)은 분지되거나(branched)[즉, M2는 M1, M3, M4 등의 각각을 직접 공급함] 단계적으로 되거나(cascaded) 또는 연속적일[즉, M2 는 M1을 공급하고, M1은 그 다음에 M3를 공급하고 M3는 그 다음에 M4를 공급하는 등.] 수 있다.

다른 구성에서, 초기 컴퓨터, 예를 들어 M2는 초기 로딩을 수행할 수 있고, 그 다음에 컴퓨터(M2)에 의해 로딩된 모든 클래스들을 목록화하는(list) 하나의 테이블을 발생시킬 수 있다. 이 테이블은 그 다음에 (분지 또는 단계적 방식으로) 다른 모든 컴퓨터들로 보내진다. 그 다음에, M2가 아닌 하나의 컴퓨터가 테이블에 열거된 하나의 클래스에 액세스할 필요가 있을 때, 그것은 M2에게 필요한 정보를 제공하도록 요청한다. 따라서, 컴퓨터(Mn)에 제공된 정보는, 일반적으로, 컴퓨터(M2)로 로딩된 초기 상태와 상이하다.

상술한 상황하에서, 테이블의 각 엔트리(entry)는, 하나의 클래스가 로딩되는 각 경우에 증가되는(incremented) 하나의 카운터(counter)에 의해 수행될(accompanied) 필요가 있다. 따라서, 데이터가 요구되면, 클래스 콘텐츠와 상응하는 카운터의 카운트가 그러한 요구에 답하여 이전된다(transferred). 이 "온 디맨드(on demand)" 모드는 각 컴퓨터의 오버헤드를 증가시키나, 컴퓨터들을 상호연결하는 통신 네트워크상의 트래픽의 볼륨(volume of traffic)을 감소시킨다.

또 다른 구성에서, 컴퓨터들(M1 내지 Mn)은, (도 15의) 하나의 부가 컴퓨터(X)에 모든 로드 요청(load requests)을 보낼 수 있는데, 이 부가 컴퓨터는, 상술한 임의의 메쏘드를 통해 변경을 실행하고, 역내(locally) 클래스를 로딩하는 컴퓨터들(M1 내지 Mn)의 각각에 변경된 클래스를 되돌려보낸다. 이 구성에서, 컴퓨터들(M1 내지 Mn)은 임의의 클래스에 대한 레코드의 테이블을 유지하지 않으며, 그 대신, 컴퓨터(X)로 모든 로드 요청을 보내는데, 이 부가 컴퓨터는 로딩된 클래스들의 테이블을 유지하고, 특정 클래스가 컴퓨터들(M1 내지 Mn)에 로딩된 것이 첫 번째인지의 여부에 따라 각 컴퓨터로 하나의 변경된 클래스를 되돌려보낸다. 컴퓨터(X)에 의해 실행된 변경은 본 발명의 범위로 커버되는 여하한 변경들을 포함할 수 있다.

도 14를 다시 참조하면, JAVA 언어에서, 초기화 루틴 <clinit>은 특정 클래스 파일(50A)이 로딩될 때 한 번만 발생한다. 그러나, 초기화 루틴 <init>은, 종종 예를 들어 하나의 새로운 오브젝트(50X, 50Y 또는 50Z)가 만들어질 때마다 종종 발생한다. 또한, 하나의 단일 클래스(50A)와 세 개의 오브젝트들(50X-50Z)을 가지는, 도 14에 도시된 응용 프로그램에서, 제1 클래스(50A)가 첫 번째로 로딩되고, 그 다음에 제1 오브젝트(50X)가 로딩되며, 그 다음에 제2 오브젝트(50Y)가 로딩되고, 마지막으로 제3 오브젝트(50Z)가 로딩되도록, 클래스들이 오브젝트에 앞서 로딩된다. 도 14에서와 같이, 단 하나의 컴퓨터(72)만이 있을 경우, 그 때는 도 14의 단일 컴퓨터가 특정 오브젝트들(50X-50Z)이 앞으로 프로그램(50)에 대해 필요하게 되기 쉬울 것인지의 여부에 대한 추적(track)을 쉽게 계속할 수 있기 때문에, 로딩 프로시저 동안 동작하도록 의도된 초기화 루틴의 가동에 충돌 또는 불일치가 발생하지 않는다. 이것은 "핸들 카운트(handle count)"를 유지함에 의해 또는 그와 유사하게 행해진다. 이 카운트는 하나의 특정 오브젝트를 참조하는 실행가능한 코드에서의 플레이스(places)의 개수의 추적을 계속한다. 특정 오브젝트에 대한 핸들 카운트가 0에 도달하면, 오브젝트를 참조하는 실행가능한 코드가 어디에도 없다. 이 오브젝 트는 그러면 "finalize 가능(finalizable)"으로 불리운다.

일단 이 상태가 달성되면, 오브젝트는 더 이상 필요하지 않기 때문에 안전하게 삭제[또는 클린 업 또는 종결(finalized)]될 수 있다. 동일한 프로시저가 필요한 변경을 가하여(mutatis mutandis) 클래스들에 대해 적용된다. 특히, 컴퓨터 프로그래머는 JAVA 언어와 아키텍쳐를 사용하여 프로그램을 만들 때 이 클린 업, 삭제 또는 종결(finalization)에 대비하기 위하여 특정 코드를 기록할 필요가 없다. 그 대신에, 하나의 단일 JAVA 가상 머신(72)이 클래스와 오브젝트 핸들 카운트에 대한 추적을 계속할 수 있고, 조심성있는 방식으로 필요한 클린 업(또는 종결을 실행)할 수 있다.

그러나, 도 8(그리고 또한 도 31-33)에 도시된 구성에서, 각기 하나의 통신 네트워크(53)를 통해 상호연결되고 각기 [도 5에서와 같은 것으로서, 도 8의 DRT(71)에 의해 실현되는] 하나의 변경자(51)를 구비하며 하나의 공통 응용 프로그램(50)으로 로딩되는 복수의 개별 컴퓨터들(M1, M2 . . . Mn)이 구비된다. 본질적으로 변경자(51) 또는 DRT(71)는 복수의 개별적인 컴퓨터들(M1, M2 . . . Mn) 전반에 걸쳐 클린 업 루틴을 실행하기 위하여 응용 프로그램 코드(50)를 변경시킨다. 그러므로, 그러한 컴퓨팅 환경에서 각 개별 컴퓨터들이 (다른 것들에 대해) 일관된 방식으로 종결되는 것을 확보할 것이 필요한 것은 사실이다.

특히, 하나의 특정 컴퓨터(예를 들어, M3)가 하나의 오브젝트 또는 클래스에 또 다른 콜(call)을 가지지 않을 수 있는 반면, 다른 컴퓨터(예를 들어 M5)는 여전히 그 오브젝트 또는 클래스를 장래에 참조할 필요가 있다. 따라서, 오브젝트 또는 클래스가 컴퓨터(M3)로부터 삭제되어야 하고 그 다음에 컴퓨터(M5)가 그 오브젝트에 기록하고 그 값을 수정하게 되면, 그 때는 컴퓨터(M3)가 그 로컬 메모리에 관련 오브젝트를 포함하지 않을 것이기 때문에 그 값의 변화가 모든 컴퓨터들(M1, M2 . . . Mn) 전체에 걸쳐 전파될 수 없다. 또한, 컴퓨터(M3)가 하나의 특정 오브젝트 또는 클래스의 클린업 루틴을 실행한다면, 클린업 루틴은 바로 그 컴퓨터의 오브젝트만을 위해서가 아니라 다른 모든 컴퓨터들의 모든 피어-오브젝트를 위해서도 마찬가지로 클린업을 실행할 것이다. 이와 같이, 컴퓨터(M5)의 오브젝트를 무효로 만든다(invalidate). 따라서, 동일한 응용 프로그램의 동시 동작을 위해 필요한, 컴퓨터들(M1, M2 . . . Mn)의 각각에 대해 대체로 동일한 메모리 콘텐츠를 갖게 하는 목표(goal)는 달성되지 않을 것이다.

일관된 종결 또는 클린 업을 확보하기 위하여, 응용 프로그램(50)은 클린 업 루틴을 정의하는 프로그램 단계를 검출하기 위해 정밀검사된다. 이 정밀검사는 로딩에 앞서 또는 로딩 프로시저 동안 또는 심지어 로딩 프로시저 후[그러나 응용 프로그램 코드(50)의 관련 해당 부분의 실행전에]에 발생할 수 있다. 용어 "컴파일"이 일반적으로 코드 또는 언어의 변화, 예를 들어 소스로부터 오브젝트 코드로 또는 하나의 언어에서 다른 언어로의 변화를 포함하는 것을 조건으로 그것은 컴파일 프로시저에 비유될 수 있다. 그러나, 바로 이 인스턴스에서 용어 "컴파일"(및 그 문법적 동등어)은 그렇게 제한적이지 않으며, 마찬가지로 동일한 코드 또는 언어내에서의 변경을 포함할 수도 있다.

그 결과로서, 상술한 정밀검사에서 클린 업 루틴들을 처음에 찾다가 발견되면 하나의 변경된 클린 업 루틴을 발생시키기 위해 하나의 변경 코드가 삽입된다. 삭제될 클래스 또는 오브젝트가 다른 모든 컴퓨터들에 의한 삭제를 위해 표지되지(marked) 않으면, 이 변경된 클린 업 루틴은 어떤 하나의 특정 컴퓨터의 클린 업 루틴을 중단시키게 된다. 여러 가지 상이한 모드들이 있으며, 이들에 의해 이 변경과 로딩이 수행될 수 있다. 이 점에 대하여, 부록 C를 참조하면, 여러 가지 클린 업 또는 종결 모드들의 예들이 제시되어 있다.

이에 따라, 하나의 모드에서, 로딩 머신(이 예에서는 JVM#1)의 DRT(71/1)는 모든 다른 컴퓨터들(M2 . . . Mn)의 DRT들(71/2 . . . 71/n)에게, 예를 들어 제1 오브젝트(50X)가 임의의 다른 컴퓨터(M2 . . . Mn)에 의해 이용되는지(즉, 삭제를 위해 표지되지 않았는지)를 질문한다. 만약 이 질문에 대한 답변이 "yes" 이면, 그 때는 일반적인 클린 업 프로시저가 로딩 머신(JVM#1)의 첫 번째 오브젝트(50X)에 대해 무력화된다. 만약 답변이 "no" 이면, 그 때는 일반적인 클린 업 프로시저가 동작되어, 첫 번째 오브젝트(50X)가 로딩 머신(JVM#1)에서 뿐만 아니라 다른 모든 컴퓨터들(M2 . . . Mn)에서도 삭제된다. 클린 업 태스크(clean up task)는 삭제를 위해 오브젝트 또는 클래스를 표지하는 마지막 컴퓨터(M1)에 할당되는 것이 바람직하다.

도 22는 종결과 관련하여 뒤따르게 될 바람직한 일반적인 프로시저를 나타낸 도면이다. 로딩(161A)이 시작된 후에, 실행될 명령어들이 차례차례 고려되고(considered), 모든 클린 업 루틴들이 단계(162)에 나타낸 바와 같이 검출된다. JAVA 언어에서 이들은 "finalize( )" 루틴(또는 JAVA 용어로 메쏘드)이다. 다른 언 어들은 상이한 용어들을 사용한다.

하나의 클린 업 루틴이 검출되면, 일반적으로 또 다른 명령어들을 루틴에 삽입함으로써 단계(163A)에서 변경된다. 이와 달리, 변경 명령어들이 루틴 앞에 삽입될 수 있다. 일단 변경이 완결되면, 로딩 프로시저가 단계(164A)에 나타낸 바와 같이 계속된다.

도 23은 변경의 특정 형태를 도시한 것이다. 첫째로, 클린 업될 가능한 후보자들인, 구조, 애셋 또는 리소스[JAVA에서는 클래스 또는 오브젝트로 명명됨](50A,50X . . . 50Y)는, 단계(172A)에 의해 표시된 바와 같이, 모든 컴퓨터들(M1, M2 . . . Mn)에 의해 광범위하게(globally) 사용될 수 있는 하나의 네임 또는 태그가 이미 할당되어 있다. 이것은 클래스 또는 오브젝트가 본래(originally) 초기화될 때 일어나는 것이 바람직하다. 이것은 서버 컴퓨터(X)에 의해 유지되는 하나의 테이블을 통해 가장 편리하게 행해진다. 이 테이블은 또한 클래스 또는 오브젝트의 클린 업 상태를 포함한다. 바람직한 실시예에서, 이 테이블은 이 애셋을 삭제를 위해 표지한 컴퓨터들의 개수의 카운트를 저장하는 하나의 카운터를 또한 포함한다. 따라서, (n-1)보다 적은 전체 카운트 값은 네트워크 전체로서 애셋에 대한 "두 낫 클린 업(do not clean up)" 상태를 나타낸다.

도 23에 도시된 바와 같이, 글로벌 네임이 다른 모든 컴퓨터들(즉, 클린 업 루틴을 실행하도록 제안된 컴퓨터들을 제외한 모든 컴퓨터들)에서 삭제를 위해 표지되지 않으면, 이것은, 단계(175A)에 의해 나타낸 바와 같이 그 오브젝트 또는 클래스가 여전히 필요하기 때문에, 오브젝트 또는 클래스의 제안된 클린 업 루틴이 중 단되어야 함을 의미한다.

그러나, 글러벌 네임이 모든 컴퓨터에서 삭제를 위해 표지되면, 이것은 이 클래스나 오브젝트를 필요로 하는 다른 컴퓨터가 없다는 것을 의미한다. 그 결과로서, 단계(176A)에 표시된 정규의(regular) 클린 업 루틴이 수행될 수 있으며, 수행되어야 한다.

도 24는 클린 업 루틴을 실행할 것을 서비 컴퓨터(X)에 제안하는 컴퓨터(M1, M2 . . . Mn)의 하나에 의해 만들어진 질문을 나타낸다. 이 제안 컴퓨터(proposing machine is)의 동작은, 답변이 단계(182A)에 표시된 컴퓨터(X)로부터 수신될 때까지, 단계(181A)와 단계(182A)에 도시된 바와 같이 일시적으로 중단된다.

도 25는, 그러한 질문에 대한 응답으로 컴퓨터(X)에 의해 수행되는 활동(activity)을 나타낸 것이다. 클린 업 상태는 단계(192A)에 나타낸 바와 같이 결정되며, 만약 답변이 "no" - 지명된 리소스(named resource)가 (n-1) 컴퓨터들에서 삭제를 위해 표지되지 않으면(즉, 다른 곳에서 이용되면), 그러한 내용의 답변이 질문 컴퓨터(enquiring machine)(194A)으로 보내지나, "삭제를 위한 표지(marked for deletion)" 카운터는, 단계(197A)에 나타낸 바와 같이, 하나(1)가 인크레멘트된다(incremented). 이와 유사하게, 만약 답변이 "yes" 이면, 이에 해당하는 답변이 단계(195A)에 나타낸 바와 같이 보내진다. 질문 대기 컴퓨터(waiting enquiring machine)(182A)가 그 다음에 이에 따라 답변할 수 있다. 도 25에 파선으로 나타낸 바와 같이, 단계(195A)에 나타낸 "yes" 답변에 더하여, 광범위하게 지명된 애셋(globally named asset)의 상태가 단계(194A)에 의해 표시된 바와 같이 "클린 업"으로 변화되도록 공유 테이블이 업데이트되는 것이 바람직하다.

도 14를 다시 참조하면, 도 14의 단일 컴퓨터는, 프로그래머의 동기화 루틴의 사용에 의해 특정될 때 특정 오브젝트들(50X-50Z)의 동기화를 쉽게 실행할 수 있다. 각 오브젝트가 국부적으로만 존재하기 때문에, 도 14의 단일 JAVA 가상 머신(72)은, 하나의 오브젝트가 프로그래머에 특정된 바와 같이 적절히 동기화되고, 이에 따라 하나의 시점에서(at any single point in time) 실행가능 코드의 하나의 부분에 의해 이용만 되도록 확보할 수 있다. 만약 실행가능 코드의 또 다른 부분이 동일한 오브젝트를 사용하고자 할 경우, 그 때는 응용 프로그램의 다른 실행 부분들이 첫 번째 부분이 끝날(finished) 때까지 기다려야만 하도록 하여, 발생가능한 경합(possible contention)이 JAVA 가상 머신(72)에 의해 해결된다.

동일한 프로시저가 필요한 변경을 가하여 클래스(50A)에 대해 적용된다. 특히, JAVA 언어와 아키텍쳐를 사용하여 프로그램을 작성할 때 컴퓨터 프로그래머는 이 경합을 피하기 위하여 동기화 루틴(들)을 사용하기만 할 필요가 있다. 따라서, 하나의 단일 JAVA 가상 머신은 클래스와 오브젝트의 이용에 대한 추적을 계속할 수 있고, 조심성있는 방식으로 해당 문제들을 필요에 따라 피할 수 있다. 단 하나의 오브젝트 또는 클래스가 독점적으로 사용되는 이 프로세스를 "동기화"라고 부른다. JAVA 언어에서 명령어 "monitorenter"와 "monitorexit"는, 경합의 대상(subject)이되지 못하게 하는 하나의 "로크"의 획득과 해제를 각각 가져오는(result in), 하나의 동기화 루틴의 시작과 끝을 의미한다.

그러나, 도 8(그리고 또한 도 31-33)에 도시된 구성에 있어서, 각기 하나의 통 신 네트워크(53)를 통해 상호연결되고 각기 [도 5에 나타낸 것과 같은 것이며, 도 8의 DRT(71)에 의해 실현되는] 하나의 변경자(modifier)(51)가 구비되고 하나의 공통 응용 프로그램(50)이 로딩되는, 복수의 개별 컴퓨터들 또는 컴퓨터들(M1, M2 . . . Mn)이 구비된다. 본질적으로 변경자(51) 또는 DRT(671)는, 컴퓨터들중의 하나에서 동작하는 응용 프로그램(50)의 일부가 하나의 오브젝트(50X-50Z) 또는 클래스(50A)와 같은 하나의 특정 로컬 애셋을(예를 들어, 동기화에 의해) 독점적으로 이용하면, 다른 컴퓨터들(M2 . . . Mn)은 그 로컬 메모리내의 상응하는 애셋을 사용하지 않는다.

특히, 하나의 특정 컴퓨터(예를 들어, M3)가 하나의 오브젝트 또는 클래스를 독점적으로 사용하는 동안, 다른 컴퓨터(예를 들어, M5)가, 그것이 실행하고 있는 코드에 의해, 그 때 그 오브젝트 또는 클래스를 독점적으로 사용하도록, 지시받을 수도 있다. 따라서, 오브젝트 또는 클래스가 두 개의 컴퓨터들에 의해 독점적으로 사용되어야 한다면, 그 때는 이 오브젝트와 응용 프로그램의 양태(behaviour)가 전체로서 "undefined" 되며, 즉, 프로그래머에 의해 명백하게 특정된 하나의 오브젝트의 적절한 독점적 사용이 없어서, 컴퓨터(M5)과 컴퓨터(M3) 사이의 영구적인 불일치(permanent inconsistency)가 일어나기 쉽다. 따라서, 동일한 응용 프로그램의 동시 동작을 위해 필요한, 컴퓨터들(M1, M2 . . . Mn) 각각에 대해 대체로 동일한 메모리 콘텐츠를 갖고자 하는 목표는 달성되지 않을 것이다.

일관된 동기화를 확보하기 위해, 응용 프로그램이 하나의 동기화 루틴을 정의하는 프로그램 단계들을 검출하기 위해 정밀검사된다. 이 정밀검사는 로딩에 앞서, 또는 로딩 프로시저 동안, 또는 심지어 로딩 프로시저 후[그러나 응용 프로그램 코드의 관련 해당 부분의 실행 전]에 일어날 수 있다. 용어 "컴파일"이 일반적으로 코드 또는 언어의 변화, 예를 들어 소스 코드로부터 오브젝트 코드로 또는 하나의 언어에서 다른 언어로의 변화를 포함하는 것을 조건으로 그것은 컴파일 프로시저에 비유될 수 있다. 그러나, 바로 이 인스턴스에서 용어 "컴파일"(및 그 문법적 동등어)은 그렇게 제한적이지 않으며, 마찬가지로 동일한 코드 또는 언어내에서의 변경을 포함할 수도 있다.

첨부된 부록 D에 관하여 언급하면, 부록 D에서:

부록 D1 은 하나의 미변경 동기화 루틴으로부터의 하나의 전형적인 코드 프래그먼트이고, 그리고

부록 D2 는 하나의 변경 동기화 루틴에 대한 하나의 동등물이다.

부록 D1 및 D2 는 각각 하나의 동기화 루틴의 전과 후의 발췌(excerpt)이다. 메쏘드에 부가된 변경된 코드는 굵은 표시로 강조되어 있다. 부록 D1의 오리지널 코드 샘플에서, 그 코드는 동기화 스테이트먼트(synchronize statement)내에서 하나의 공유 메모리 위치(카운터)를 인크레멘트시킨다(increment). 동기화 스테이트먼트의 목적은 다중-스레드 응용 프로그램(multi-threaded applications)에서 인크레멘트 동작(increment operation)의 스레드-안전(thread-safety)을 확보하는 것이다. 따라서, 분배 환경에서 동기화를 관리하지 않으면, 각 컴퓨터는 분리해서(in isolation) 동기화를 실행하게 될 것이고, 그리하여 공유 카운터를 동시에 잠재적으로 인크레멘트시키며, 점재적인 레이스 조건(들)[potential race condition(s)] 과 흐트러진 메모리(incoherent memory)의 원인이 된다. 이것은 응용 프로그램의 프로그래머가 일어날 것으로 예상하는 것이 명백히 아니다.

그러므로, 응용 프로그램 코드는, DRT를 이용하여, 그것이 동기화 루틴을 변화시킴으로써 컴퓨터에 로딩되어 응용 프로그램 코드가 변경된다. 만들어진 변화들(굵게 강조되어 있음)은, 동기화 루틴이 실행하는 최초 명령어들과 최종 명령어들이다. 이 부가된 명령어들은 분배 환경에서 다른 모든 컴퓨터들에 걸쳐 동기화를 추가로 실행하도록 동작하고, 이에 따라 복수의 컴퓨터들에 걸쳐 응용 프로그램의 동기화 행위(synchronize behaviour)를 보호한다.

DRT 메쏘드의 acquireLock()는, 이 오브젝트를 위한 독특한 식별자를 대표하는 하나의 인수(argument)를 취하는데(부록 D2 참조), 그것은 예를 들어 특정 오브젝트의 하나의 글로벌 로크를 획득하는데 사용되는 그 오브젝트의 네임, 문제의 오브젝트에 대한 하나의 레퍼런스(reference), 또는 모든 노드(nodes)에 걸쳐 이 오브젝트를 나타내는 독특한 번호(unique number)이다. 이런 식으로, 공유 동기화 테이블의 정확한 레코드를 조사하기(consult) 위해 각 오브젝트의 독특한 식별자를 사용함으로써, 복수 오브젝트들중 어느 것이 이미 동기화되고, 어떤 것이 동기화되지 않은 것인지에 대한 혼동없이, 동시에 복수 오브젝트의 동기화를 지지할 수 있다.

DRT는 여러 방식으로 오브젝트의 동기화 상태를 결정할 수 있다. 그것은 각 컴퓨터에 대해, 이 오브젝트의 그 로컬 카피가 현재 동기화되는지 질문하고, 그리고 어떤 컴퓨터가 "true"이라고 답변하면, 그 오브젝트가 미동기화될(unsynchronized) 때까지 기다리게 하고, 그렇지 않으면, 이 오브젝트를 국부적으로 동기화하도록 차 례로 요청할 수 있다. 이와 달리, 로컬 컴퓨터의 DRT는, 이 오브젝트가 다른 컴퓨터에 의해 동기화된 것으로 표지되었는지를 결정하고, 그리고 만약 그렇다면, 오브젝트의 상태가 "미동기화(unsynchronised)"로 변화될 때까지 기다리고, 그 오브젝트를 동기화된 것으로 표지함으로써 로크를 획득하며, 그렇지 않으면, 그 오브젝트가 이 컴퓨터에 의해 동기화된 것으로 표지함으로써 로크를 획득하기 위해, [아마도 하나의 별개 컴퓨터(예를 들어 컴퓨터(X))의] 하나의 공유 레코드 테이블 또는 로컬 컴퓨터의 하나의 코히런트 공유 레코드 테이블, 또는 데이터베이스를 조사할 수 있다.

만약, 이 오브젝트에 대한 하나의 로크를 현재 가지는 다른 컴퓨터가 없는[즉, 이 오브젝트를 동기화한 다른 컴퓨터가 없는] 것으로 DRT가 결정하면, 예를 들어 동기화 상태의 하나의 공유 테이블내의 상응하는 엔트리(entry)를 변경시킴으로써, 또는 이와 달리 현재 컴퓨터에 더하여 다른 모든 컴퓨터에 그 로크를 순차적으로(sequentially) 획득함으로써 다른 모든 컴퓨터에서 이 오브젝트에 대한 그 로크를 획득한다. 이 컴퓨터가 이 오브젝트를 현재 동기화한 다른 컴퓨터가 없음을 성공적으로 확인할 때만 그리고 이 컴퓨터가 상응하게 국부적으로 동기화될 때만, 오리지널 동기화 코드-블록(original synchronized code-block)의 실행이 시작될 수 있다.

반면에, 다른 컴퓨터가 이미 이 오브젝트를 동기화한 것으로, DRT가 결정하면, 이 컴퓨터는, 이 오브젝트에 대한 동기화 스테이트먼드를 현재 실행하고 있는 다른 컴퓨터가 없음과 이 컴퓨터가 그 오브젝트를 국부적으로 상응하게 동기화시켰음을 DRT가 확인할 수 있을 때까지, 이 컴퓨터는 오리지널 동기화 코드-블록의 실행을 연기하게 된다. 그러한 경우에, 동기화 스테이트먼트의 공동 실행(concurrent execution)의 결과로 일어나는 레이스-조건, 메모리의 불일치 등으로 인해 참여 컴퓨터들(participating machines) 전체에 걸쳐 그 오브젝트에 오류를 일으킬(corrupt) 가능성이 있기 때문에, 이 컴퓨터가 이 오브젝트에 대한 하나의 동기화 스테이트먼트를 실행하고 있는 다른 컴퓨터가 없음을 보증할 수 있을 때까지 오리지널 코드 블록은 실행되게 되지 않게 된다. 따라서, DRT가 이 오브젝트가 현재 "동기화된(synchronized)" 것으로 결정하면, DRT는, 해당 "releaseLock()" 동작이 그 로크의 현재 소유자에 의해 실행될 때까지, "acquireLock()" 동작의 실행을 일시중지함으로써(pausing) 오리지널 코드-블록의 실행을 막는다.

따라서, "releaseLock()" 동작의 실행에서, 현재 하나의 로크를 "소유하는(owns)" (예를 들어, 동기화 스테이트먼트를 실행하는) 컴퓨터는, 예를 들어 이 오브젝트를 "동기화처리되지 않음(unsynchronised)"이라고 동기화 상태의 공유 테이블에 표지함으로써, 또는 이와 달리 다른 모든 컴퓨터에 획득된 로크들을 순차적으로 해제함으로써, 그 동기화 스테이트먼트의 닫기(close)를 표시한다. 이 시점에, 해당 동기화 스테이트먼트의 실행을 시작하기를 기다리는 다른 컴퓨터는 그 때, 그 연기된(즉, 지연된) "acquireLock()" 동작의 실행을 다시 시작함으로써, 예를 들어 동기화 상태의 공유 테이블의 이 오브젝트에 대한 동기화 스테이트먼트를 실행하는 것으로 그 자신을 표지함으로써(marking itself), 또는 이와 달리 다른 컴퓨터들 각각에 로컬 로크들을 순차적으로 획득함으로써, 그 오브젝트 로크의 소 유권(ownership of this objects lock)을 주장할 수 있다.

그러므로, 응용 프로그램 코드는, [하나의 최초 "monitorenter" 및 하나의 최종 "monitorexit" 명령어들로 구성된] 동기화 루틴을 변화시킴으로서 컴퓨터로 로딩되기 때문에, DRT를 이용하여, 응용 프로그램 코드가 변경된다. (굵게 강조된) 변화된 것들은, 동기화 루틴이 실행한 초기 명령어들이다. 이들 추가된 명령어들은, 이 로크가 다른 컴퓨터에 의해 이미 획득되었는지를 체크한다. 이 로크가 다른 컴퓨터에 의해 획득되지 않았으면, 그 때는 이 컴퓨터의 DRT가 다른 모든 컴퓨터들에게 이 컴퓨터가 그 로크를 획득하였음을 알리고, 이에 따라 다른 컴퓨터들이 이 로크에 대한 동기화 루틴을 실행하는 것을 멈추게 된다.

DRT는 여러 방식으로 컴퓨터들의 로크 상태를 기록할 수 있으며, 예를 들면 다음과 같다:

1. 하나의 동기화 루틴에 대한 엔트리(entry)에 상응하여, DRT는 이 로크가 이미 획득되었는지를 확인하기 위해 개별적으로 각 컴퓨터를 조사한다(consult). 만약 그러하다면, DRT는 다른 모든 컴퓨터들이 이 애셋 또는 오브젝트에 더 이상 하나의 로크를 소유하지 않을 때까지 동기화 루틴의 실행을 일시중지한다. 그렇지 않으면, DRT는 이 동기화 루틴을 실행한다. 이와 달리,

2. 하나의 동기화 루틴에 대한 엔트리에 상응하여, DRT는, 어느 컴퓨터가 이 로크를 현재 "소유(owns)"하는지를 나타내는 레코드들의 공유 테이블[예를 들어 하나의 공유 데이터베이스, 또는 참여 컴퓨터들의 각각의 하나의 공유 테이블의 하나의 카피]을 조사한다. 만약 그러하다면, DRT는 다른 모든 컴퓨터들이 더 이상 이 오브젝트에 하나의 로크를 소유하지 않을 때까지 이 컴퓨터에서 동기화 루틴의 실행을 일시중지한다. 그렇지 않으면, DRT는 이 컴퓨터를 공유 테이블[또는, 예를 들어 복수 컴퓨터에 레코드의 복수 테이블들이 있는 경우에는, 테이블들]에 이 로크의 소유자로 기록하고, 그 다음에 동기화 루틴을 실행한다.

이와 유사하게, 하나의 로크가 해제되면, 즉, 하나의 동기화 루틴의 실행이 끝나게 되면, DRT는 여러 다른 방식으로 컴퓨터들의 로크 상태를 "미기록(un-record)" 할 수 있는데, 예를 들면 다음과 같다:

1. 하나의 동기화 루틴에 대한 엑시트(exit)에 상응하여, DRT는, 다른 각 컴퓨터들에게 그것이 더 이상 로크를 소유하지 않음을 개별적으로 통지한다. 이와 달리,

2. 하나의 동기화 루틴에 대한 엑시트에 상응하여, DRT는, 이 컴퓨터가 더 이상 이 로크를 소유하는 것으로 기록되지 않도록 이 로크된 애셋 또는 오브젝트에 대한 레코드들의 공유 테이블(들)의 레코드를 업데이트한다.

그외에도, DRT는 여러 다른 방식으로 하나의 로크된 오브젝트를 획득할 필요가 있는 컴퓨터들을 큐처리할(queue) 수 있는데, 예를 들면 다음과 같다:

1. 하나의 동기화 루틴에 대한 엔트리에 상응하여, DRT는 로크된 오브젝트의 현재 소유자에게, 그 로크가 현재 소유 컴퓨터에 의해 해제되면 하나의 특정 컴퓨터가 이를 획득하고자 한다는 것을 통지한다. 다른 대기 컴퓨터들이 없을 경우, 그 특정 컴퓨터는 하나의 테이블에 그 특정 컴퓨터의 오브젝트 획득에 대한 관심의 기록을 저장하며, 이 테이블은 로크된 오브젝트의 동기화 루틴의 엑시트에 뒤이어, 그 다음에 대기 컴퓨터에게 그것이 이 로크된 오브젝트를 획득할 수 있고 이에 따라 그 동기화 루틴을 실행하는 것을 시작할 수 있음을 통지하며,

2. 하나의 동기화 루틴에 대한 엔트리에 상응하여, DRT는 로크된 오브젝트의 현재 소유자에게 그 로크가 컴퓨터[예를 들어, 컴퓨터(M4)]에 의해 해제되면 하나의 특정 컴퓨터[예를 들어, 컴퓨터(M6)]이 이를 획득하고자 한다는 것을 통지한다. 그 컴퓨터(M4)는 대기 컴퓨터들의 이 로크된 오브젝트에 대한 자신의 레코드들(its records)을 조사한 후에, 하나 또는 그보다 많은 컴퓨터들이 이미 대기하고 있었음을 발견하면, 이 로크된 오브젝트를 획득하기 위해 대기하는 컴퓨터들의 목록의 끝에 컴퓨터(M6)를 추가하거나, 그와 달리 첫 번째 대기, 또는 다른 대기 컴퓨터에 컴퓨터(M6)로부터의 요청을 전달하고, 그 대기 컴퓨터는 그 다음에 차례로 그 레코드 테이블에 컴퓨터(M6)를 기록하고,

3. 하나의 동기화 루틴에 대한 엔트리에 상응하여, DRT는 공유 레코드 테이블들(a shared table(s) of records)[예를 들어, 모든 컴퓨터들에 의해 액세스가능한 하나의 공유 데이터베이스에 저장된 하나의 테이블, 또는 대체로 유사한 복수의 개별 테이블들]에 그 자신을 기록한다.

그 외에도, DRT는, 이 컴퓨터에 의한 하나의 동기화 루틴의 엑시트에 상응하여 이 로크를 획득하고자 하는 대기중인(queued) 다른 컴퓨터들에 다른 방식으로 통지할 수 있는데, 예를 들면 다음과 같다:

1. 하나의 동기화 루틴의 엑시트에 상응하여, DRT는 대기 컴퓨터들중의 하나[예를 들어, 대기 컴퓨터들중의 대기열(queue)에서 첫 번째 컴퓨터]에게 이 로크가 해제되는 것을 통지하고,

2. 하나의 동기화 루틴의 엑시트에 상응하여, DRT는 대기 컴퓨터들중의 하나[예를 들어, 대기 컴퓨터들중의 대기열에서 첫 번째 컴퓨터]에게 이 로크가 해제되는 것을 통지하고, 추가로 컴퓨터들[예를 들어, 이 로크를 기다리는 제2 대기 컴퓨터와 그 다음의 컴퓨터들]의 전체 대기열의 하나의 카피를 제공한다. 이런 식으로, 각 컴퓨터가 목록를 따라 차례로 로크를 획득하고 그 후에 해제함에 따라, 제2 대기 컴퓨터가 제1 대기 컴퓨터로부터 대기 컴퓨터들의 목록를 물려받고, 이에 따라 대기 컴퓨터들의 대기열의 연속성을 확보한다.

상술한 정밀검사 동안에, "monitor enter"와 "monitor exit" 명령어들(또는 방법들)을 처음에 찾아서 발견하면, 하나의 변경된 동기화 루틴을 발생시키기 위해 하나의 변경 코드를 삽입한다. 이 변경된 루틴은 하나의 로크를 획득하고 해제한다. 이러한 변경과 로딩이 실행될 수 있게 해주는, 여러 가지 상이한 모드들이 있다. 부록 D는 추가 정보를 제공한다.

도 26은 동기화에 관하여 뒤따르게될 바람직한 일반적인 프로시저를 나타낸 도면이다. 로딩(161B)이 시작된 후에, 실행될 명령어들이 차례로(in sequence) 고려되고, 모든 동기화 루틴들이 단계(162B)에 나타낸 바와 같이 검출된다. JAVA 언어에서 이들은 "monitor enter"와 "monitor exit" 명령어들이다. 다른 언어들은 상이한 용어들을 사용한다.

하나의 동기화 루틴이 검출된 경우, 그것은, 또 다른 명령어들을 루틴에 삽입함으로써 변경되는 것이 일반적이다. 이와 달리, 변경 명령어들이 루틴 앞에 삽입 될 수 있다. 일단 변경이 완료되면 로딩 프로시저가 계속된다. 그 변경들은, 단계(163B)에 나타낸 바와 같이, 하나의 "acquire lock on all other machines" 동작과 하나의 "release lock on all other machines" 변경의 형태를 취하는 것이 바람직하다.

도 27은 변경의 특정 형태를 도시한 도면이다. 첫째로, 동기화될 구조, 애셋 또는 리소스[JAVA 언어에서는, 예를 들어 50A, 50X-50Y의 클래스 또는 오브젝트로 명명됨]는, 단계(172B)에 나타낸 바와 같이, 모든 컴퓨터들에 의해 광범위하게 사용될 수 있는 하나의 네임 또는 태그가 이미 할당되어 있다. 이것은 클래스 또는 오브젝트가 처음부터 초기화될 때 발생하는 것이 바람직하다. 이것은 서버 컴퓨터(X)에 의해 유지되는 하나의 테이블을 통해 가장 편리하게 행해진다. 이 테이블은 또한 클래스 또는 오브젝트의 동기화 상태를 포함한다. 바람직한 실시예에서, 이 테이블은 또한 이 애셋의 사용을 요청한 컴퓨터들의 아이덴티티를 저장하는 하나의 대기열의 구성(queue arrangement)을 포함한다.

도 27의 단계(173B)에 나타낸 바와 같이, 하나의 "acquire lock" 요청을 컴퓨터(X)로 발송한 다음에는, 단계(174B)에 나타낸 바와 같이, 그 발송 컴퓨터(sending machine)가 로크 획득의 확인(confirmation)을 위해 기다린다. 따라서, 글로벌 네임이 이미 로크되어(locked) 있으면[즉, 상응하는 애셋이 로크의 획득을 제안한 컴퓨터가 아닌 다른 컴퓨터에 의해 사용중이면], 이것은 오브젝트 또는 클래스가 현재 소유자에 의해 로크가 풀릴(unlocked) 때까지 오브젝트 또는 클래스의 제안된 동기화 루틴이 일시중지되어야 함을 의미한다.

이와 달리, 글로벌 네임이 고정되어(locked) 있지 않으면, 이것은 이 클래스 또는 오브젝트를 사용하는 다른 컴퓨터가 없음을 의미하며, 그에 따라 로크 획득의 확인이 즉시 수신된다. 로크 획득의 확인의 수신 후에, 단계(175B)에 나타낸 바와 같이, 동기화 루틴의 실행이 계속되도록 허용된다.

도 28은, 하나의 로크를 포기하기를 바라는, 응용 프로그램 실행 컴퓨터가 따를 프로시저를 나타낸 도면이다. 초기 단계가 단계(181B)에 나타나 있다. 이 포기 제안 컴퓨터(proposing machine)의 동작은, 단계(184B)에 상응하여, 답변이 컴퓨터로부터 수신될 때까지 단계(183B, 184B)에 의해 일시적으로 중단되고, 그 다음에 단계(185B)에 나타낸 바와 같이 실행이 시작된다. 선택적으로, 그리고 단계(182B)에 나타낸 바와 같이, 하나의 로크의 해제를 요청하는 컴퓨터는, 컴퓨터(X)에 대한 요청에 앞서 이 로크에 대한 "글로벌 네임"을 검색(lookup)하게 된다. 이런 식으로, 다중 컴퓨터들의 다중 로크들은 서로 간섭없이 획득될 수 있고 해제될 수 있다.

도 29는 (도 27의) 하나의 "로크 획득" 질문에 대한 응답으로 컴퓨터(X)에 의해 수행되는 활동을 나타낸 도면이다. 단계(191B)에서 "로크 획득" 요청을 수신한 후에, 단계(192B와 193B)에서 로크 상태가 결정되고, 만약 "no" 이면 - 명명된 리소스가 자유롭지 않으면, 단계(194B)에서 질문 컴퓨터의 식별부호(identity)가 대기 획득 요청의 대기열에 추가되거나, 대기 획득 요청의 대기열을 형성된다. 이와 달리, 답변이 "yes" 이면, 명명된 리소스가 자유로우면-, 상응하는 답변이 단계(197B)에서 보내진다. 질문 대기 컴퓨터는 그 때 도 27의 단계(175B)를 수행함으 로써 동기화 루틴을 실행할 수 있다. "yes" 답변에 더하여, 공유 테이블은, 포괄적으로 명명된 애셋의 상태가 "로크됨(locked)"으로 변경되도록, 단계(196B)에서 업데이트된다.

도 30은 도 28의 "로크 해제" 요청에 대한 답변으로 컴퓨터(X)에 의해 수행되는 활동을 나타낸 도면이다. 단계(201)에서 하나의 "로크 해제" 요청을 수신한 후에, 컴퓨터(X)은 선택적으로, 그리고 바람직하게, 단계(202)에 나타낸 바와 같이, "로크"의 해제를 요청한 컴퓨터가 정말로 로크의 현재 소유자인지 확인한다. 다음에는, 단계(203)에서 대기열 상태가 결정되고, 만약 아무도 이 로크를 획득하기를 기다리지 않는다면, 컴퓨터(X)는 이 로크를 공유 테이블에 "미소유(unowned)"로 표지하고, 선택적으로 요청 컴퓨터로 해제 확인(a confirmation of release)을 돌려 보낸다. 이것은 요청 컴퓨터로 하여금 도 28의 단계(185B)를 실행하는 것을 가능하게 한다.

이와 달리, "yes" 이면 - 즉, 다른 컴퓨터들이 이 로크를 획득하기를 기다린다면-, 단계(204)에 나타낸 바와 같이, 이 로크를 대기열의 다음 컴퓨터에 의해 방금 획득된 것으로 대기열에 표지하고, 그 다음에 단계(205)에서 대기열에 있는 컴퓨터에게 로크 획득의 확인을 보내고, 그 결과로서 대기 컴퓨터들의 대기열로부터 새로운 로크 소유자를 단계(206)에 나타낸 바와 같이 제거한다.

도 31 내지 도 33을 이제 참조하면, 두 개의 랩탑 컴퓨터들(101 및 102)이 도시되어 있다. 컴퓨터들(101 및 102)은 반드시 동일하여야 하는 것은 아니며, 실제로 하나는 IBM 또는 모조 IBM 일 수 있으며, 다른 하나는 애플(APPLE) 컴퓨터일 수 있다. 컴퓨터들(101 및 102)은 두 개의 스크린들(105, 115), 두 개의 키보드들(106, 116), 그러나 하나의 싱글 마우스(107)를 가진다. 두 개의 컴퓨터들(101, 102)은 하나의 단일 동축 케이블(single coaxial cable) 또는 꼬인 페어 케이블(twisted pair cable)(314)에 의해 상호연결된다.

두 개의 단순한 응용 프로그램들이 각 컴퓨터(101, 102)로 다운로드되고, 변경되어(modified) 있는 그 프로그램들은 상술한 바와 같이 로딩된다. 이 실시예에서, 첫 번째 응용 프로그램은 하나의 단순한 계산기 프로그램(calculator program)이고, 스크린(105)에 표시된 하나의 계산기(108)의 이미지를 갖게 된다. 두 번째 프로그램은, 4 색상의 블록들(109)을 표시하는 하나의 그래픽 프로그램으로서, 이 블록들은 상이한 색상들을 가지며, 직사각형 상자(310)내에서 일정하지 않고 옮겨 다닌다. 다시 말해서, 로딩 후에, 박스(310)가 스크린(105)에 표시된다. 각 응용 프로그램은, 블록들(109)이 스크린(105)상에서 불규칙하게 이동하는 반면, 계산기(108)내의 숫자들은, 계산기(108)가 답을 표시(display)하도록, (덧셈 또는 곱셈과 같은) 하나의 수학적 연산자(mathematical operator)와 함께 [마우스(107)에 의해] 선택될 수 있도록 독립적으로 동작한다.

마우스(107)는, 도 32에 도시된 상황에 도달하기 위해, 박스(310)를 "붙들기(grab)" 위해 그리고 이를 바로 스크린(105)을 가로질러 스크린(115)으로 이동시키기 위해 사용될 수 있다. 이 구성에서, 계산기 응용 프로그램은 컴퓨터(101)에서 수행되는(conducted) 반면, 박스(310)의 표시로 나타나는 그래픽 응용 프로그램은 컴퓨터(102)에서 수행된다.

그러나, 도 33에 도시된 바와 같이, 계산기(108)의 일부가 스크린들(105, 115)의 각각에 의해 표시되도록 하기 위해, 마우스(107)에 의해 계산기(108)를 도 32에 나타낸 바와 같이 오른쪽으로 끌어내는 것이 가능하다. 이와 유사하게, 도 33에 나타낸 바와 같이 박스(310)가 각 스크린(105, 115)에 의해 부분적으로 표시되도록, 박스(310)를 도 32에 나타낸 바와 같이 마우스(107)에 의해 좌측으로 끌어낼 수 있다. 이러한 구성(configuration)에서, 계산기 동작의 일부는 컴퓨터(101)에서 수행되고 또 다른 일부는 컴퓨터(102)에서 수행되는 반면, 그래픽 응용 프로그램의 일부가 컴퓨터(101)에서 수행되고 그 나머지는 컴퓨터(102)에서 수행된다.

전술한 것은 본 발명의 몇몇 실시예들만을 기술한 것이며, 당업자들에게 명백한 본 발명의 변형이 본 발명의 범위를 벗어나지 않고 만들어질 수 있다. 예를 들어, JAVA에 대한 언급은 JAVA 언어 그리고 또한 JAVA 플랫폼(platform) 및 아키텍쳐를 모두 포함한다.

프로그래밍 업계의 당업자들은, 부가 코드 또는 명령어들이 이들을 변경시키도록 설정된 하나의 현존 코드(existing code) 또는 명령어에 삽입되는 경우, 오프셋(offsets), 브랜칭(branching), 속성(attributes), 마크 업(mark up) 등이 제공되도록(catered for), 이 현존 코드 또는 명령어 세트(set)가 [예를 들어 연속하는 명령어들의 재-넘버링(re-numbering)에 의해] 또 다른 변경을 자주 필요로 할 것임을 알 것이다.

이와 유사하게, JAVA 언어에서, 메모리 위치들은, 예를 들어 필드(fields)와 어레이 타입(array types)을 포함한다. 상술한 것은 필드를 취급하며, 어레이 타입 에 대해 필요한 변화는 필요한 변경을 가하여 근본적으로 동일하다. 본 발명은 Micrsoft.NET 플랫폼과 아키텍쳐(Visual Basic, Visual C/C++, 및 C#), 포트란(FORTRAN), C/C++, 코볼(COBOL), 베이직(BASIC) 등을 포함하는 JAVA와 유사한 프로그래밍 언어[프로시저에 관한(procedural), 선언적인(declarative) 그리고 오브젝트 지향적인(object orientated) 것 포함]에 똑같이 적용가능하다.

JAVA 초기화 루틴의 코드가 변경되는 상기 실시예는, 각 컴퓨터(M1 . . . Mn)의 실행 시간 시스템(run time system)(예를 들어, C 및 JAVA로 기록된 JAVA HOTSPOT 가상 머신) 또는 운영 체계[예를 들어, C 및 어셈블러(Assembler)로 기록된 LINUX]의 어느 하나가 JAVA 초기화 루틴을 콜링할(call) 것이라는 가정을 기초로 한다. 오브젝트 또는 클래스가 이미 로딩되었다면, JAVA 초기화 루틴이 콜링되지 않도록, JAVA 초기화 루틴을 수정되지 않은 채로(unamended) 남겨두고, JAVA 초기화 루틴을 콜링하는 LINUX 또는 HOTSPOT 루틴을 그 대신 수정하는 것이 가능하다. 그러한 구성을 포함하기 위해, 용어 "초기화 루틴"은, JAVA 초기화 루틴과, JAVA 초기화 루틴을 콜링하거나 시작하는(initiate) LINUX 또는 HOTSPOT 코드 프래그먼트들과 JAVA 초기화 루틴의 "조합(combination)"을 그 범위내에 포함하는 것으로 이해되어야 한다.

JAVA 종결 또는 클린 업 루틴의 코드가 변경되는 상기 실시예는 각 컴퓨터(M1 . . Mn)의 실행 시간 시스템[예를 들어, C 및 JAVA로 기록된 JAVA HOTSPOT 가상 머신] 또는 운영 체계[예를 들어, C 및 어셈블러로 기록된 LINUX]의 어느 하나가 JAVA 종결 루틴을 콜링할 것이라는 가정을 기초로 한다. 만일, 오브젝트 또는 클래스가 삭제되지 않게 된다면, JAVA 초기화 루틴이 콜링되지 않도록, JAVA 초기화 루틴을 수정되지 않은 채로 남겨두고, JAVA 초기화 루틴을 콜링하는 LINUX 또는 HOTSPOT 루틴을 대신 수정하는 것이 가능하다. 그러한 구성을 포함하기 위해, 용어 "종결 루틴"은, JAVA 종결 루틴과, JAVA 종결 루틴을 콜링하거나 시작하는 LINUX 또는 HOTSPOT 코드 프래그먼트들과 JAVA 종결 루틴의 "조합"을 그 범위내에 포함하는 것으로 이해되어야 한다.

JAVA 동기화 루틴의 코드가 변경되는 상기 실시예는, 각 컴퓨터(M1 . . Mn)의 실행 시간 시스템[예를 들어, C 및 JAVA로 기록된 JAVA HOTSPOT 가상 머신] 또는 운영 체계[예를 들어 C 및 어셈블러로 기록된 LINUX]의 어느 하나가 로컬 컴퓨터(예를 들어, M2)에서 일반적으로 로크를 획득하되, 다른 컴퓨터들(M1, M3 . . . Mn)에서 획득하지 않을 것이라는 가정을 기초로 한다. 다른 모든 컴퓨터들에서 로크를 마찬가지로 획득하도록, JAVA 동기화 루틴을 수정되지 않은 채로 남겨두고, 국부적으로 로크를 획득하는 LINUX 또는 HOTSPOT 루틴을 대신 수정하는 것이 가능하다. 그러한 구성을 포함하기 위해, 용어 "동기화 루틴"은, JAVA 동기화 루틴과, 로크 획득 및 해제를 실행하는 LINUX 또는 HOTSPOT 코드 프래그먼트들과 JAVA 동기화 루틴의 "조합"을 그 범위내에 포함하는 것으로 이해되어야 한다.

본 명세서에 사용된 오브젝트와 클래스는 JAVA 환경으로부터 파생된 것으로서, 동적 링크 라이브러리(dynamically linked libraries; DLL), 또는 오브젝트 코드 팩키지(object code packages), 또는 기능 유닛 또는 메모리 위치(function unit or memory locations)와 같은 상이한 환경으로부터 파생된 유사한 용어를 포함하는 것으로 의도된다.

본 명세서에 사용된 용어 "포함하여 구성되는(comprising)" (및 그 문법적 변형)은 "가지는(having)" 또는 "포함하는(including)"을 포함하는 의미로 사용되며, "~만을 포함하는(consisting only of)"의 배제적인 의미로 사용되는 것은 아니다.

저작권 고지

본 특허 명세서는 저작권 보호를 받는 자료들을 포함한다. (본 출원인인) 저작권자는, 검토를 위해 공중이 입수가능한 해당 특허청 파일로부터 이 특허 명세서 또는 관련 자료들을 복제하는 것에 이의를 제기하지 않으나, 만약 그렇지 않으면 어떤 경우든지 모든 저작권을 보유한다. 특히, 여러 명령어들은 저작권자의 명확한 서면으로 된 승인없이는 컴퓨터에 입력되어서는 안된다.

Claims (139)

1. 하나의 통신 네트워크에 의해 상호연결된 복수의 컴퓨터들에서 동시에 동작하는 적어도 하나의 응용 프로그램을 가지며, 상기 응용 프로그램(들)의 실행은 상기 응용 프로그램(들)의 상이한 부분들이 상기 컴퓨터들 중 상응하는 상이한 것들에서(on different ones of said computers) 동시성으로(contemporaneously) 실행되도록 상기 컴퓨터들 사이에서 공유되고, 각각의 상응하는 컴퓨터에 대해 상응하는 세트의 복수의 오브젝트들(a corresponding set of a plurality of objects)이 만들어지며, 각각의 세트에서 오브젝트들의 수가 동일하며 각각의 세트에서 상응하는 오브젝트들이 동일하고(identical), 상기 컴퓨터 각각에 의한 모든 판독 요청들이 요청하는 컴퓨터에서 만들어진 오브젝트들을 판독함으로써만 만족되며,

   상기 컴퓨터들의 각각이, 상기 통신 네트워크에 의해서 업데이트되도록 의도된 적어도 하나의 메모리 위치를 갖는 로컬 메모리(local memory); 상기 통신 네트워크에 연결하기 위한 통신 포트(communication port); 및 복제되는 로컬 메모리 위치(들)의 임의의 업데이트된 콘텐츠(들)을 상기 통신 포트에 전달함으로써 다중 컴퓨터 시스템의 컴퓨터들 각각의 상응하는 복제되는 메모리 위치는 상기 통신 네트워크에 의해서 업데이트될 수 있게 하며 상기 복제되는 메모리 위치들은 모두 동일함(identical)을 유지할 수 있게 하는 업데이팅 수단(updating means)을 포함하는,

   다중 컴퓨터 시스템.
2. 제1항에 있어서, 상기 복수의 동일한 오브젝트들이 각각, 하나의 동일한 네임을 가지는, 다중 컴퓨터 시스템.
3. 제2항에 있어서, 상기 동일하게 명명된 오브젝트들의 각각의 초기 콘텐츠가 동일한, 다중 컴퓨터 시스템.
4. 제2항에 있어서, 동일한 오브젝트들의 군 각각은, 상기 복수의 컴퓨터들 각각이 상기 오브젝트들 군의 그 해당 오브젝트를 더 이상 참조할 필요가 없을 때, 모두 집합적으로(collectively) 삭제되는, 다중 컴퓨터 시스템.
5. 제4항에 있어서, 상기 각 컴퓨터가 다른 모든 컴퓨터들과 통신할 수 있는 그러한 분배 실행 시간 수단을 상기 각 컴퓨터가 포함하고, 그에 따라, 상기 컴퓨터들 중의 하나에서 동작하는 상기 응용 프로그램(들)의 일부분이 그 컴퓨터의 하나의 오브젝트를 참조하는 것을 더 이상 필요로 하지 않으면, 그 비참조 오브젝트(unreferenced object)의 아이덴티티(identity)가 다른 모든 컴퓨터에 의해 액세스가 가능한 공유 테이블로 상기 하나의 컴퓨터의 분배 실행 시간 수단에 의해 전달되는, 다중 컴퓨터 시스템.
6. 제5항에 있어서, 상기 각 응용 프로그램이, 하나의 오브젝트를 더 이상 참조할 필요가 없는 각 인스턴스를 변경하기 위한 하나의 종결 루틴(finalization routine)을 삽입함으로써, 로딩(loading) 전, 로딩 동안, 또는 로딩 후에 변경되는, 다중 컴퓨터 시스템.
7. 제6항에 있어서, 모든 컴퓨터들이 더 이상 그 상응하는 오브젝트를 참조할 필요가 없으면 미리-존재하는(pre-existing) 종결 루틴을 실행하도록 하고(enable), 적어도 하나의 컴퓨터가 상응하는 하나의 오브젝트를 참조할 필요가 있으면 미리-존재하는 종결 루틴을 디세이블(disable) 시키도록 상기 삽입된 종결 루틴이 하나의 미리-존재하는 종결 루틴을 변경시키는, 다중 컴퓨터 시스템.
8. 제2항에 있어서, 상기 모든 컴퓨터들에 적용가능한 하나의 로크 수단(lock means)을 포함하고; 하나의 명명된 오브젝트를 사용하고자 하는 어느 컴퓨터가, 그러한 오브젝트 사용을 허락하고 다른 모든 컴퓨터들은 그러한 사용 허락이 포기될 때까지 그 해당 명명 오브젝트를 사용하는 것을 금지하는 허가 로크(authorizing lock)를 상기 로크 수단으로부터 획득하게 되어 있는; 다중 컴퓨터 시스템.
9. 제8항에 있어서, 상기 로크 수단이 하나의 로크 획득 루틴(acquire lock routine)과 하나의 로크 해제 루틴(release lock routine)을 포함하고, 상기 모든 컴퓨터들에서 동작하는 상기 응용 프로그램에 만들어진 변경부분(modifications)에 상기 두 루틴들이 포함되는, 다중 컴퓨터 시스템.
10. 제9항에 있어서, 상기 로크 수단이, 상기 컴퓨터들 중 어느 것에 의해 사용중인 상기 명명된 오브젝트들, 상기 각 오브젝트에 대한 하나의 로크 동작상태(lock status) 그리고 로크 획득 미결정분들(pending lock acquisitions)의 하나의 대기열(queue)을 목록화하는(listing) 하나의 공유 테이블(shared table)을 더 포함하는, 다중 컴퓨터 시스템.
11. 제10항에 있어서, 상기 로크 수단이, 상기 응용 프로그램을 동작시키지 않으며 상기 통신 네트워크에 연결된, 하나의 부가 컴퓨터 내에 위치되는, 다중 컴퓨터 시스템.
12. 제11항에 있어서, 하나의 오브젝트에 대한 하나의 로크를 각각 획득하고 해제시키는 각 인스턴스를 변경하기(modify) 위하여, 상기 로크 획득 루틴과 상기 로크 해제 루틴을 삽입함으로써, 상기 각 응용 프로그램이 로딩의 전, 로딩 동안, 또는 로딩 후에 변경되는, 다중 컴퓨터 시스템.
13. 제1항 내지 제12항 중 어느 한 항에 있어서, 상기 각 컴퓨터가 그것으로 다른 모든 컴퓨터들과 통신할 수 있는 하나의 분배 업데이트 수단(distribution update means)을 포함하고, 그에 따라, 상기 컴퓨터들 중 하나에서 동작하는 상기 응용 프로그램(들)의 일부분이 그 컴퓨터의 오브젝트의 콘텐츠들을 변화시키면, 상기 오브젝트에 대한 콘텐츠의 변화가 상기 하나의 컴퓨터의 분배 업데이트 수단에 의해 다른 모든 컴퓨터들로 전파되어(propagated) 상기 다른 컴퓨터들 각각의 해당 오브젝트의 콘텐츠를 변화시키는, 다중 컴퓨터 시스템.
14. 제13항에 있어서, 모든 상기 분배 업데이트 수단이 로컬 메모리 판독 속도(local memory read rate)보다 작은 데이터 전달 속도(data transfer rate)로 상기 통신 링크를 통해 통신하는, 다중 컴퓨터 시스템.
15. 제1항 내지 제12항 중 어느 한 항에 있어서, 상기 응용 프로그램이 메모리에 기록하는 각 인스턴스를 변경시키기 위해, 업데이팅 전파 루틴(updating propagation routine)을 삽입함으로써 상기 각 응용 프로그램이 로딩 전, 로딩 동안, 또는 로딩 후에 변경되고, 상기 업데이팅 전파 루틴이 하나의 컴퓨터에 의한 각 메모리 기록(every memory write)을 상기 다른 모든 컴퓨터들에 전파하는, 다중 컴퓨터 시스템.
16. 제1항 내지 제12항 중 어느 한 항에 있어서, 상기 응용 프로그램이 오브젝트를 만드는 각 인스턴스를 변경시키기 위해, 초기화 루틴(initialization routine)을 삽입함으로써 상기 각 응용 프로그램이 로딩 전, 로딩 동안, 또는 로딩 후에 변경되고, 상기 초기화 루틴이 하나의 컴퓨터에 의한 각 메모리 기록을 다른 모든 컴퓨터들에 전파하는, 다중 컴퓨터 시스템.
17. 제16항에 있어서, 상기 복수의 오브젝트들 중 첫 번째가 만들어지면 미리-존재하는 초기화 루틴이 실행될 수 있도록(enable) 하고, 상기 복수의 오브젝트들 중 이후의 모든 것들이 만들어지면 미리-존재하는 초기화 루틴을 디세이블시키도록, 상기 삽입된 초기화 루틴이 미리-존재하는 초기화 루틴을 변경시키는, 다중 컴퓨터 시스템.
18. 제17항에 있어서, 상기 응용 프로그램이, 로딩에서의 재-컴파일, 로딩에 앞선 전-컴파일, 로딩에 앞선 컴파일, 저스트-인-타임 컴파일, 그리고 응용 프로그램의 관련 부분의 로딩 후 및 실행 전의 재-컴파일로 구성되는 프로시저들(procedures)의 군으로부터 선택된 하나의 프로시저에 따라 변경되는, 다중 컴퓨터 시스템.
19. 제18항에 있어서, 상기 변경 응용 프로그램이, 마스터/슬레이브 전달, 분지적 전달 및 단계적 전달로 구성되는 군으로부터 선택된 하나의 프로시저에 따라 상기 모든 컴퓨터들로 전달되는, 다중 컴퓨터 시스템.
20. 제1항 내지 제12항 중 어느 한 항에 있어서, 상기 응용 프로그램에 또는 상기 각 응용 프로그램에 할당된 상기 로컬 메모리 용량이 동일하고 상기 응용 프로그램이 또는 상기 각 응용 프로그램이 사용할 수 있는 전체 메모리 용량이 상기 할당된 메모리 용량인, 다중 컴퓨터 시스템.
21. 제1항 내지 제12항 중 어느 한 항에 있어서, 상기 컴퓨터들의 적어도 상당수가 상이한 제조업자들에 의해 제조되고 그리고/또는 상이한 운영 체계들을 가지는, 다중 컴퓨터 시스템.
22. 하나의 통신 네트워크에 의해 상호연결된 복수의 컴퓨터들에서 동시에 적어도 하나의 응용 프로그램을 동작시키는 것으로서,

    (i) 상기 응용 프로그램(들)의 상이한 부분들이 상기 컴퓨터들 중 상응하는 상이한 것들에서 동시성으로(contemporaneously) 실행되도록 상기 컴퓨터들 사이에서 상기 응용 프로그램(들)의 실행을 공유하고, 그리고 각각의 상응하는 컴퓨터에 대해 상응하는 세트의 복수의 오브젝트들을 만드는 단계로서, 각각의 세트에서 오브젝트들의 수가 동일하며 각각의 세트에서 상응하는 오브젝트들이 동일한 것인 단계와;

    (ii) 요청하는 컴퓨터(requesting computer)에 만들어진 오브젝트들로부터만 판독함으로써 상기 각 컴퓨터에 의한 모든 판독 요청들(all read requests)을 만족시키는 단계;를 포함하여 구성되는, 적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
23. 제22항에 있어서,

    (iii) 상기 복수의 동일한 오브젝트들 각각을 하나의 동일한 네임으로 명명하는 단계를 더 포함하여 구성되는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
24. 제22항에 있어서,

    (iv) 만일 상기 컴퓨터들 중의 하나에서 동작하는 상기 응용 프로그램의 일부분이 그 컴퓨터의 하나의 오브젝트의 콘텐츠들를 변화시키면, 다른 컴퓨터들 각각에서 상응하는 오브젝트의 콘텐츠를 변화시키기 위하여 상기 오브젝트의 콘텐츠의 변화가 상기 통신 네트워크를 통해 다른 모든 컴퓨터들로 전파되는 단계를 더 포함하여 구성되는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
25. 제24항에 있어서,

    (v) 상기 응용 프로그램이 메모리에 기록하는 각 인스턴스(each instance at which said application program writes to memory)를 변경하기 위하여, 하나의 컴퓨터에 의해 각 메모리 기록(every memory write)을 상기 다른 모든 컴퓨터들로 전파하는 하나의 업데이팅 전파 루틴을 삽입함으로써 상기 응용 프로그램을 로딩 전, 로딩 동안, 또는 로딩 후에 변경시키는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
26. 제25항에 있어서,

    (vi) 로딩에서의 재-컴파일, 로딩에 앞선 전-컴파일, 로딩에 앞선 컴파일, 저스트-인-타임 컴파일, 그리고 응용 프로그램의 관련부분의 로딩 후 및 실행 전의 재-컴파일로 구성되는 프로시저들의 군으로부터 선택된 하나의 프로시저를 이용하여 상기 응용 프로그램을 변경시키는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
27. 제26항에 있어서,

    (vii) 상기 변경된 응용 프로그램을, 마스터/슬레이브 전달, 분지적 전달 및 단계적 전달로 구성되는 군으로부터 선택된 하나의 프로시저를 이용하여 상기 모든 컴퓨터들로 전달하는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
28. 제25항에 있어서,

    (viii) 로컬 메모리 판독 속도보다 작은 하나의 데이터 전송 속도로 하나의 업데이팅 데이터 전송을 구성하는 상기 로컬 메모리 기록들(local memory writes)을 전달하는(communicating) 단계를 더 포함하여 구성되는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
29. 제23항에 있어서,

    (iⅹ) 상기 동일하게 명명된 오브젝트들 각각의 초기 콘텐츠들을 동일하게 만드는 단계를 더 포함하여 구성되는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
30. 제29항에 있어서,

    (ⅹ) 만약 상기 컴퓨터들 중 하나에서 동작하는 상기 응용 프로그램의 일부분이 그 컴퓨터에 하나의 오브젝트를 만들면, 그 만들어진 오브젝트가 상기 통신 네트워크를 통해 다른 모든 컴퓨터들로 전파되는 단계를 더 포함하여 구성되는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
31. 제30항에 있어서,

    (ⅹi) 상기 응용 프로그램이 하나의 오브젝트를 만드는 각 인스턴스를 변경하기 위하여, 하나의 컴퓨터에 의해 만들어진 각 오브젝트 마다 상기 다른 모든 컴퓨터들로 전파하는 하나의 초기화 루틴을 삽입함으로써, 로딩 전, 로딩 동안 또는 로딩 후에 상기 응용 프로그램을 변경시키는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
32. 제31항에 있어서,

    (ⅹii) 로딩에서의 재-컴파일, 로딩에 앞선 전-컴파일, 로딩에 앞선 컴파일, 저스트-인-타임 컴파일, 그리고 응용 프로그램의 관련 부분의 로딩 후 및 실행 전의 재-컴파일로 구성되는 프로시저들의 군으로부터 선택된 하나의 프로시저를 이용하여 상기 응용 프로그램을 변경시키는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
33. 제32항에 있어서,

    (ⅹiii) 상기 변경된 응용 프로그램을 마스터/슬레이브 전달, 분지적 전달 및 단계적 전달로 구성되는 군으로부터 선택된 하나의 프로시저를 이용하여 상기 모든 컴퓨터들로 전달하는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
34. 제22항 내지 제33항 중 어느 한 항에 있어서,

    (ⅹiv) 상기 복수의 컴퓨터들이 모두 그들의 상응하는 오브젝트를 참고하는 것이 더 이상 필요하지 않은 때, 상기 동일한 오브젝트들을 모두 집합적으로 삭제하는 단계를 더 포함하여 구성되는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
35. 제34항에 있어서,

    (ⅹv) 상기 통신네트워크를 통해서 상기 컴퓨터들 사이에 통신하기 위한 하나의 분배 실행 시간 수단을 상기 각 컴퓨터에 제공하는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
36. 제35항에 있어서,

    (ⅹvi) 상기 각 분배 실행 시간 수단에 의해 액세스 가능하고, 그리고 하나의 오브젝트에 액세스하는 것이 더 이상 필요하지 않은 컴퓨터의 어느 것이든 그 아이덴티티가 그 오브젝트의 아이덴티티와 함께 저장되는 하나의 공유테이블을 제공하는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
37. 제36항에 있어서,

    (ⅹvii) 상기 오브젝트에 액세스하는 것이 더 이상 필요하지 않는 상기 컴퓨터들의 수의 하나의 카운트(count)를 저장하는, 하나의 카운터수단을 상기 공유테이블과 연관시키는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
38. 제37항에 있어서,

    (ⅹviii) 상기 공유 프로그램이 동작하지 않으며, 상기 공유 테이블과 카운터를 호스팅하며(host), 상기 통신네트워크에 연결되어 있는 하나의 부가 컴퓨터를 제공하는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
39. 제22항 내지 제33항 중 어느 한 항에 있어서,

    (ⅹviv) 하나의 명명된 오브젝트를 사용하고자 하는 상기 컴퓨터들 중 어느 것이든, 그러한 사용을 허가하고 다른 모든 컴퓨터들은 그러한 사용 허락이 포기될 때까지 그 해당 명명 오브젝트를 사용하는 것을 금지하는 허가 로크(authorizing lock)를 획득할 것을 요구하는 단계를 더 포함하여 구성되는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
40. 제39항에 있어서,

    (ⅹⅹ) 상기 통신 네트워크를 통해 상기 컴퓨터들 간에 통신하기 위하여 하나의 분배 실행 시간 수단을 상기 각 컴퓨터에 제공하는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
41. 제40항에 있어서,

    (ⅹⅹi) 상기 각 분배 실행 시간 수단에 의해 액세스가능하고, 하나의 오브젝트에 현재 액세스해야만 하는 어느 컴퓨터의 아이덴티티가 그 오브젝트의 아이덴티티와 함께 저장되어 있는, 하나의 공유 테이블을 제공하는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
42. 제41항에 있어서,

    (ⅹⅹii) 상기 오브젝트에 대해 액세스하려고 하는 상기 컴퓨터들의 수의 하나의 카운트(count)를 저장하는 하나의 카운트 수단을 상기 공유 테이블과 연관시키는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
43. 제42항에 있어서,

    (ⅹⅹiii) 상기 공유 프로그램이 동작하지 않으며, 상기 공유 테이블과 카운터를 호스팅하고(host), 상기 통신 네트워크에 연결된 하나의 부가 컴퓨터를 제공하는 단계를 더 포함하는,

    적어도 하나의 응용 프로그램을 복수의 컴퓨터들에서 동시에 동작시키는 방법.
44. 삭제
45. 삭제
46. 삭제
47. 삭제
48. 삭제
49. 삭제
50. 삭제
51. 삭제
52. 삭제
53. 삭제
54. 삭제
55. 삭제
56. 삭제
57. 삭제
58. 삭제
59. 삭제
60. 삭제
61. 삭제
62. 삭제
63. 삭제
64. 삭제
65. 삭제
66. 삭제
67. 삭제
68. 삭제
69. 삭제
70. 삭제
71. 삭제
72. 삭제
73. 삭제
74. 삭제
75. 삭제
76. 삭제
77. 삭제
78. 삭제
79. 삭제
80. 삭제
81. 삭제
82. 삭제
83. 삭제
84. 삭제
85. 삭제
86. 삭제
87. 삭제
88. 삭제
89. 삭제
90. 삭제
91. 삭제
92. 삭제
93. 삭제
94. 삭제
95. 삭제
96. 삭제
97. 삭제
98. 삭제
99. 삭제
100. 삭제
101. 삭제
102. 삭제
103. 삭제
104. 삭제
105. 삭제
106. 삭제
107. 삭제
108. 삭제
109. 삭제
110. 삭제
111. 삭제
112. 삭제
113. 삭제
114. 삭제
115. 삭제
116. 삭제
117. 삭제
118. 삭제
119. 삭제
120. 삭제
121. 삭제
122. 삭제
123. 삭제
124. 삭제
125. 삭제
126. 삭제
127. 삭제
128. 삭제
129. 삭제
130. 삭제
131. 삭제
132. 삭제
133. 삭제
134. 삭제
135. 삭제
136. 삭제
137. 삭제
138. 삭제
139. 삭제

Images