[go: up one dir, main page]

KR100470555B1 - 컴퓨터 자원의 로크방법 및 장치 - Google Patents

컴퓨터 자원의 로크방법 및 장치 Download PDF

Info

Publication number
KR100470555B1
KR100470555B1 KR10-1999-7006607A KR19997006607A KR100470555B1 KR 100470555 B1 KR100470555 B1 KR 100470555B1 KR 19997006607 A KR19997006607 A KR 19997006607A KR 100470555 B1 KR100470555 B1 KR 100470555B1
Authority
KR
South Korea
Prior art keywords
register
computer
lock
processor
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
KR10-1999-7006607A
Other languages
English (en)
Other versions
KR20000070374A (ko
Inventor
조이윌리엄엔.
오코너제임스마이클
트렘블레이마크
Original Assignee
선 마이크로시스템즈 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 선 마이크로시스템즈 인코포레이티드 filed Critical 선 마이크로시스템즈 인코포레이티드
Publication of KR20000070374A publication Critical patent/KR20000070374A/ko
Application granted granted Critical
Publication of KR100470555B1 publication Critical patent/KR100470555B1/ko
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/30101—Special purpose registers

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Multi Processors (AREA)
  • Executing Machine-Instructions (AREA)

Abstract

본 발명은 컴퓨터 자원의 로크장치 및 방법에 관한 것으로, 컴퓨터 프로세서는 다수의 레지스터 쌍 LOCKADDR/LOCKCOUNT을 포함하고, 각각의 쌍에서 LOCKADDR/LOCKCOUNT 레지스터는 컴퓨터 자원을 위한 로크를 식별하는 값을 보유하며, 로크 명령이 발생되면 대응하는 LOCKCOUNT 레지스터가 인크리먼트되고, 언로크 명령이 발생되면 대응하는 LOCKCOUNT 레지스터가 디크리먼트되며, LOCKCOUNT 레지스터와 관련된 카운트가 제로까지 디크리먼트되면 로크가 해제되고, 이러한 구조는 빈번하게 발생하는 상황에서 고속의 로크 및 언로크 방법을 제공하며, 일부 실시예에서, LOCKCOUNT 레지스터가 생략되고 로크에 대응하는 임의의 언로크 명령상에서 로크가 해제되며, 일부 실시예에서, 컴퓨터 오브젝트는 클래스 구조에 대한 포인터를 포함하는 헤더를 포함하고, 클래스 구조는 4바이트 한계로 정렬되며, 따라서 클래스 구조로의 포인터의 2개 LSBs는 제로가 되고 헤더에 기억되지 않으며, 대신 2개 헤더 LSBs는: (1) 오브젝트가 로크되는지 여부를 나타내는 LOCK 비트, 및 (2) 스레드가 오브젝트에 대한 로크를 받아들이기 위해 기다리고 있는지 여부를 나타내는 WANT 비트를 기억하는 것을 특징으로 한다.

Description

컴퓨터 자원의 로크방법 및 장치{LOCKING OF COMPUTER RESOURCES}
본 발명은 컴퓨터 자원의 로크(locking)에 관한 것이다.
컴퓨터 프로세스 또는 스레드(thread)와 같은 여러 컴퓨터 엔티티들이 컴퓨터 자원(예를 들어, 데이터, 코드, 또는 하드웨어 일부)을 공유하는 경우, 다른 컴퓨터 엔티티에 의한 일부 형태의 자원 액세스를 방지하기 위해 컴퓨터 엔티티들중의 하나가 잠시동안 자원을 로크하도록 허용하는 것이 바람직하다. 예를 들어, 만일 둘 이상의 스레드가 컴퓨터 데이터를 공유하고, 하나의 스레드가 상기 데이터를 수정하기 시작했지만 아직 종료하지 않았을 때 또다른 스레드가 데이터를 액세스하는 경우, 다른 스레드는 데이터로부터 부정확한 정보를 얻을 수 있고, 또는 상기 데이터가 두 개의 스레드에 의해 변조될 수 있다. 또한, 만일 하나의 스레드가 시작되었지만, 또다른 스레드가 동일한 코드 섹션을 실행하기 시작한 때 임계 코드 섹션의 실행을 종료하지 않았다면, 예를 들어 임계 코드 섹션이 데이터 영역, 하드웨어 제어기, 또는 일부 다른 컴퓨터 자원의 상태를 수정하는 경우 실행 에러가 발생할 수도 있다. 따라서, 컴퓨터 엔티티들이 컴퓨터 자원을 로크하도록 하기 위해 로크 방법이 제공되어왔다.
컴퓨터 자원의 로크를 위한 고속기법을 제공하는 것이 요구된다.
도 1은 본 발명에 따른 프로세서를 포함하는 컴퓨터 시스템의 블럭도,
도 2는 도 1의 프로세서내 로크 오퍼레이션에서 사용되는 레지스터를 나타내고, 또한 도 1의 시스템의 메모리내 관련 데이터 구조를 나타내는 블럭도,
도 3은 도 1의 메모리내 데이터 구조를 나타내는 블럭도, 및
도 4는 본 발명에 따른 프로세서내 로크 오퍼레이션에서 사용되는 레지스터를 나타내는 블럭도이다.
본 발명은 다수의 빈번한 발생 상황에서 컴퓨터 자원의 로크 및 언로크(unlocking)를 신속하게 하는 방법 및 회로를 제공한다. 특히, 일부 실시예에서, 로크에서 경쟁이 없는 경우(즉, 또다른 컴퓨터 엔티티에 의해 로크되고 있지 않은 경우) 일반적으로 로크가 빠르다. 또한, 동일한 컴퓨터 엔티티, 예를 들어 동일한 스레드가 로크를 해제하기전에 동일한 로크상에서 다수의 로크 오퍼레이션을 수행하는 경우 일반적으로 로크 오퍼레이션이 신속해진다. 로크가 해제되기전에 만일 스레드가 반복코드를 실행하는 경우 다수의 로크 오퍼레이션이 발생할 수 있다.
일부 실시예에서, 상기한 이점들은 다음과 같이 성취될 수 있다. 컴퓨터 프로세서는 다수의 레지스터 쌍들(LOCKADDR,LOCKCOUNT)을 포함한다. 각각의 LOCKADDR 레지스터는 컴퓨터 자원을 위한 로크를 식별하는 값을 보유한다. 일부 실시예에서, 이러한 값은 로크된 오브젝트에 레퍼런스가 된다. 따라서, 일부 실시예에서, 상기 값은 로크된 오브젝트의 어드레스가 된다. 대응하는 LOCKCOUNT 레지스터는 LOCKADDR 레지스터에 의해 식별된 로크와 관련된 로크 명령의 카운트를 보유한다. 스레드가 LOCKADDR 레지스터에 의해 식별된 로크를 위한 로크 명령을 발생시키는 경우, 컴퓨터 프로세서는 대응하는 LOCKCOUNT 레지스터를 인크리먼트(increment)한다. 스레드가 언로크 명령을 발생시키는 경우, 컴퓨터 프로세서는 대응하는 LOCKCOUNT 레지스터을 디크리먼트(decrement)한다.
일부 실시예에서, 상기 프로세서는 Java Virtual Machine의 로크 및 언로크 명령을 실행시키기에 적당하다. 예를 들어 T. Lindholm과 F. Yellin의 "The JavaTM Virtual Machine Specification"(1997)에 Java Virtual Machine가 기재되어 있다. Java Virtual Machine에서, 각각의 오브젝트는 그것과 관련된 모니터를 갖는다. 스레드가 로크 명령 "monitorenter"을 실행하는 경우, 대응하는 모니터와 관련된 카운터가 인크리먼트된다. 스레드가 언로크 명령 "monitorexit"를 실행하는 경우, 카운터가 디크리먼트된다. 일부 실시예에서, 카운터는 LOCKCOUNT 레지스터를 이용하여 구현된다.
일부 실시예에서, LOCKCOUNT 레지스터는 생략되고, 자원을 위한 로크가 상기 자원을 위해 발생된 임의의 언로크 명령으로 해제된다.
일부 실시예에서, 각각의 오브젝트는 클래스 구조로의 포인트가 되는 헤더를 포함한다. 클래스 구조는 4바이트 한계로 정렬되고, 따라서 상기 포인터의 두 개 LSBs는 제로가 되며, 헤더에 기억될 필요가 없다. 대신, 상기 헤더의 두 개 LSBs는 (1) 오브젝트가 로크되었는지 여부를 나타내는 "LOCK" 비트, 및 (2) 스레드가 오브젝트를 위한 로크를 받아들이기 위해 기다리는지 여부를 나타내는 "WANT" 비트를 기억하기 위해 사용된다.
본 발명의 다른 특징 및 이점이 후술되어 있다. 본 발명의 첨부된 청구의 범위에 의해 한정된다.
도 1은 로크 회로를 포함하는 컴퓨터 시스템의 블럭도이다. 프로세서(110)는 버스(130)에 의해 메모리(120)와 연결된다. 프로세서(110)는 메모리(120)로부터 판독된 명령을 실행하는 실행장치(136)를 포함한다. 실행장치(136)는 LOCKADDR,LOCKCOUNT로 불리는 레지스터(144)를 포함한다. 이들 레지스터들은 후술한 바와 같이 오브젝트 로크를 위해 사용된다.
버스(130)는 프로세서(110)의 메모리 인터페이스장치(150) 및 I/O 버스와 연결된다. 프로세서(110)가 메모리(120)로부터 명령을 판독하는 경우, 인터페이스장치(150)는 상기 명령을 명령 캐시(156)에 기록한다. 그리고, 명령은 디코드장치에 의해 디코딩된다. 디코딩 장치(160)는 실행제어 및 마이크로코드 장치(166)로 제어신호를 전송한다. 장치(166)는 실행 장치(136)와 제어신호를 교환한다. 디코딩 장치(160)는 또한 스택 캐시 및 스택 캐시 제어장치(170)(이하 "스택 캐시"라 함)로 제어신호를 전송한다. 스택 캐시(170)는 실행 장치(136) 및 데이터 캐시 장치(180)와 제어 및 데이터 신호를 교환한다. 캐시 장치(170,180)는 메모리(120) 내지 인터페이스(150) 및 버스(130)와 데이터를 교환한다. 실행 장치(136)는 명령 캐시(156), 스택 캐시(170), 및 데이터 캐시(180)를 플러시(flush)할 수 있다.
도 2는 레지스터(144) 및 메모리(120)내 대응하는 오브젝트들중의 하나를 나타내고 있다. 레지스터(144)는 LOCKADDR0/LOCKCOUNT0 내지 LOCKADDR3/LOCKCOUNT3로 분리된 4개의 레지스터쌍을 포함한다. 각각의 LOCKADDR 레지스터는 로크된 오브젝트의 어드레스를 보유한다. 설명되는 실시예에서, 각각의 어드레스는 32비트 길이고, 따라서 각각의 LOCKADDR 레지스터는 32비트 길이이다. 그러나, 일부 실시예에서, 각각의 오브젝트는 4바이트 한계로 시작한다. 따라서, 일부 실시예에서, 오브젝트 어드레스중 2개의 LSBs(least significant bits)는 제로이고, 레지스터 LOCKADDR로부터 생략된다. 그러한 실시예에서, 각각의 레지스터 LOCKADDR은 30비트 길이가 된다.
만일 LOCKADDR 레지스터가 0을 포함하는 경우, 이것은 상기 레지스터 쌍이 사용되지 않는다는 것을 의미한다.
각각의 레지스터 쌍에서, LOCKCOUNT 레지스터는 그 어드레스가 대응하는 LOCKADDR 레지스터에 보유되는 오브젝트를 위한 로크 명령의 카운트를 보유한다. LOCKCOUNT 레지스터는 대응하는 명령이 발생되지 않은 그 로크 명령의 갯수를 보유한다. LOCKCOUNT 레지스터는 오브젝트를 위한 각각의 로크 명령에서 인크리먼트되고, 각각의 언로크 명령에서 디크리먼트된다. 상기 로크는 LOCKCOUNT 레지스터가 제로까지 디크리먼트되는 경우에만 실제로 해제된다(그러나, 일부 실시예에서, LOCKCOUNT 레지스터는 후술하는 바와 같이 로크 카운트의 일부만을 보유한다. 전체 로크 카운트가 제로까지 디크리먼트될 때 로크가 해제된다.). 일부 실시예에서, 각각의 LOCKCOUNT 레지스터는 8비트 길이가 되어, 0과 255 사이의 수를 보유한다.
반복코드의 결과로서 언로크 명령을 개입시키지 않은 다중 로크 명령이 될 수 있다. LOCKCOUNT 레지스터가 오브젝트를 위한 로크 및 언로크 명령의 네트 카운트(즉, 오브젝트를 위한 로크 명령 및 언로크 명령의 수의 차이)를 유지하기 때문에, 소프트웨어 프로그램은 오브젝트가 스레드의 일부 다른 파트에 의해 로크되었는지 여부를 결정하기 위해 각각의 언로크 명령전에 테스트할 필요성이 없게 되므로, 그 로크 필요성이 끝날 때까지 로크되어 있어야 한다.
일부 실시예들에서, 레지스터(144)는 로크 어드레스를 유지하고, 하나의 스레드 또는 하나의 컴퓨터 프로세스만을 위해 카운트한다. 프로세서(110)가 다른 스레드 또는 프로세스로 스위치하는 경우, 레지스터(144)에는 실행될 새로운 스레드 또는 프로세스를 위한 로크 데이터(로크 어드레스 및 카운트)가 로드된다.
도 2는 LOCKADDR 레지스터(도 2에서 레지스터 LOCKADDR3)에 그 어드레스가 기억된 오브젝트를 설명하고 있다. 도 2에서, 메모리(12)에 기억된 오브젝트가 도시되어 있다. 그러나, 오브젝트 일부 또는 전부가 데이터 캐시(180)에 기억될 수 있다. 이러한 설명에서, 메모리(120)내 데이터 및 명령 기억을 기술할 때, 다른 설명이 없는한 데이터 또는 명령은 데이터 캐시(180), 스택 캐시(170), 또는 명령 캐시(156)에 기억될 수 있는 것으로 이해될 것이다.
도 2에 도시된 바와 같이, 레지스터 LOCKADDR3내 어드레스는 오브젝트 구조체(220)로의 포인터가 된다. 오브젝트 구조체(220)는 헤더(220H)와 함께 시작한다. 헤더(220H)에는 다른 데이터(도시되지 않음)가 뒤이어 있다. 헤더(220H)는 오브젝트를 설명하는 클래스 구조(230)로의 포인터를 포함한다. 클래스 구조(230)는 4바이트 한계로 정렬된다. 결과적으로, 모든 어드레스들이 앞의 바이트보다 하나 더 큰 어드레스를 갖는 각각의 연속적인 바이트를 갖는 바이트 어드레스이기 때문에, 클래스 구조체 어드레스의 두 개 LSBs는 제로가 된다. 이들 제로 LSBs는 헤더(220H)에 기억되지 않는다. 따라서, 헤더는 어드레스 기억장치에서 사용되지 않는 2개 비트를 갖는다. 이들 비트(헤더 LSBs(0,1))는 오브젝트 로크에서 사용된다. L 비트 또는 LOCK 비트라고도 불리는 비트(0)는 오브젝트가 로크될 때 1로 설정된다. W 또는 WANT 비트라고도 불리는 비트(1)는 스레드가 오브젝트(220)를 위한 로크를 받아들이기 위해 기다리며 블로크되고 있는 경우에 1로 설정된다.
본 명세서의 끝(청구의 범위전)의 부록 A 및 부록 B는 프로세서(110)의 하나의 실시예에서 로크 및 언로크 명령을 실행하는 회로를 위한 의사코드(pseudocode)를 포함한다. 상기 회로는 실행 장치(136) 및/또는 실행 제어 및 마이크로코드 장치(166) 부분이다. 부록 A 및 부록 B의 의사코드 언어는 예를 들어 본 명세서에서 참조에 의해 구체화된 D.E.Thomas, J.P.Moorby의 "The Verilog(R) Hardware Description Language"(1991)에 기재된 하드웨어 기술 언어 Verilog(R)와 유사하다. 의사코드는 쉽게 Verilog로 변환될 수 있고, 대응하는 회로는 해당 기술분야에서 공지된 방법을 이용하여 구현될 수 있다.
부록 A은 로크 명령을 위한 의사코드를 나타내고 있다. 부록 A의 단계(1-0) 내지 단계(1-3)의 각각에서, 대응하는 레지스터 LOCKADDR0 내지 LOCKADDR3의 내용은 로크될 오브젝트의 어드레스와 비교된다. 만일 매치한다면, 대응하는 레지스터 LOCKCOUNT는 인크리먼트되고(단계(1-0a,1-1a,1-2a,1-3a)), 제로와 비교된다 (단계(1-0b,1-1b,1-2b,1-3b)). 만일 LOCKCOUNT 레지스터가 인크리먼트후에 0이 되는 경우, 오버플로우가 발생하고, 트랩 LockCountOverflowIncrementTrap이 발생된다. 트랩의 발생은 명령의 실행을 종료시킨다. 만일 트랩이 이네이블되면, 프로세서(110)는 트랩을 위해 정의된 트랩 핸들러를 실행시키기 시작한다. 트랩 핸들러는 컴퓨터 프로그램이다.
일부 실시예에서, LockCountOverflowIncrementTrap을 위한 트랩 핸들러는 LOCKCOUNT 레지스터보다 더 긴 로크 카운터 mLOCKCOUNT(도 3)를 유지한다. 특히, 일부 실시예에서, OS는 메모리(120)내 테이블(310)을 이용하여 로크된 오브젝트의 트랙을 유지한다. 분리 테이블(310)은 각각의 스레드를 위해 유지된다. 테이블(310)은 스레드가 생성된 경우, 스레드를 위해 발생되고, 테이블(310)은 대응하는 스레드가 파괴된 경우 할당해제된다.
각각의 테이블(310)은 다수의 엔트리(mLOCKADDR,mLOCKCOUNT)를 포함한다. 각각의 엔트리의 기능은 레지스터 쌍(LOCKADDR/LOCKCOUNT)의 기능과 유사하다. 특히, mLOCKADDR은 스레드에 의해 로크된 오브젝트의 어드레스를 유지한다. mLOCKCOUNT는 오브젝트를 위한 스레드에 의해 발생된 로크 명령의 카운트를 보유한다. 로크 명령의 카운트는 대응하는 언로크 명령이 실행되지 않은 것에 대한 로크 명령의 수가 된다. 만일 일부 mLOCKADDR=0인 경우, 이것은 엔트리가 사용되지 않은 것을 의미한다.
테이블(310)은 4개 이상의 엔트리를 가질 수도 있다. 다른 테이블(310)은 다른 개수의 엔트리를 가질 수도 있다.
각각의 메모리 위치 mLOCKADDR은 일부 실시예에서 32 또는 30비트 길이가 된다. 각각의 위치 mLOCKCOUNT는 8 또는 그 이상의 비트 길이가 된다. 일부 실시예에서, 각각의 위치 mLOCKCOUNT는 32비트 길이가 되고, 각각의 레지스터 LOCKCOUNT는 8비트 길이가 된다.
OS가 실행을 위해 스레드를 스케쥴하는 경우, OS는 최대 4개 엔트리를 대응하는 테이블(310)로부터 레지스터쌍 LOCKADDR/LOCKCOUNT으로 로드할 수도 있다. 각각의 엔트리는 하나의 레지스터쌍 LOCKADDR/LOCKCOUNT에 기록된다. 만일 mLOCKCOUNT가 LOCKCOUNT보다 긴 경우, OS는 LOCKCOUNT(일부 실시예에서 8LSBs)에 맞는 정도의 mLOCKCOUNT의 LSBs를 LOCKCOUNT에 기록한다. 만일 일부 레지스터 쌍이 테이블(310)로부터 엔트리를 수신하지 않는 경우, OS는 레지스터쌍이 사용되지 않았다("비어있다")는 것을 나타내기 위해 대응하는 레지스터 LOCKADDR을 0으로 설정한다.
일부 실시예에서, 테이블(310)은 각각의 엔트리에 스레드가 실행을 위해 스케줄될 때 엔트리가 LOCKADDR/LOCKCOUNT 레지스터 쌍에 기록될지 여부를 나타내기 위한 하나의 비트(도시되지 않음)를 포함한다. 다른 실시예에서, 각각의 스레드에서 OS는 스레드가 실행을 위해 스케줄될 때 레지스터(144)에 기록될 엔트리의 리스트(도시되지 않음)를 유지한다. 일부 실시예에서, OS는 LOCKADDR/LOCKCOUNT 레지스터에 기록된 엔트리를 표시하기 위해 각각의 엔트리에, 또는 엔트리들의 리스트에 하나의 비트를 갖는다.
일부 경우에서, 로크 및 언로크 명령은 트랩이 발생하도록 하지 않는다. 따라서, mLOCKCOUNT LSBs는 무효일 수 있거나 또는 LOCKADDR/LOCKCOUNT 레지스터 쌍에 의해 지정된 로크를 위한 테이블(310)내 엔트리가 없을 수도 있다.
일부 스레드(T1)가 점유되고 또다른 스레드(T2)가 프로세서(110)상에서의 실행을 위해 스케쥴되는 경우, OS는 스레드(T2)의 테이블(310)로부터 레지스터를 로드하기전에 스레드(T1)의 테이블(310)로 비어있지 않은 모든 LOCKADDR/LOCKCOUNT 레지스터쌍을 기록한다. 만일 mLOCKCOUNT가 LOCKCOUNT보다 길다면, OS는 각각의 LOCKCOUNT 레지스터를 대응하는 위치 mLOCKCOUNT의 LSBs에 기록한다. 만일 현재 스레드 테이블(310)이 LOCKADDR/LOCKCOUNT 레지스터쌍에 의해 지정된 로크를 위한 엔트리를 갖지 않는다면, 엔트리는 OS에 의해 생성된다.
일부 실시예에서, LockCountOverflowTrap를 위한 트랩 핸들러는 로크될 오브젝트의 어드레스를 포함하는 mLOCKADDR으로 엔트리를 위한 현재 스레드의 테이블(310)을 탐색한다. 만일 그러한 엔트리가 존재하지 않는 경우, 트랩 핸들러는 프리 엔트리를 찾고, 그 mLOCKADDR을 로크될 오브젝트의 어드레스로 설정하며 mLOCKCOUNT를 제로로 설정한다. 둘중 한쪽의 경우(엔트리가 존재했거나 생성되기만한 경우)에, 트랩 핸들러는 LOCKCOUNT 레지스터에 기억되지 않은 mLOCKCOUNT MSBs를 인크리먼트하고, LSBs를 제로로 설정한다.
이제 다시 실행 장치(136)에 의한 로크 명령의 실행을 설명한다. 일부 실시예에서, 레지스터 LOCKADDR와 부록 A의 단계(1-0 내지 1-3)에서 로크될 오브젝트의 주소의 비교는 4개 레지스터에 대응하는 4개 비교기에 의해 동시에 수행되고, 단계(1-0a,1-1a,1-2a,1-3a)에서의 LOCKCOUNT의 인크리먼트는 인크리먼터를 이용하여 수행된다. 그러한 비교기 및 인크리먼터는 해당 기술분야에서 공지되어 있다.
실행장치(136)는 로크될 오브젝트의 헤더(220H)로부터 LOCK 비트(도 2)를 판독하고, 상기 오브젝트가 로크되었다는 것을 나타내기 위해 LOCK 비트를 1로 설정한다(단계(2a)). 이러한 판독 및 설정(테스트 및 설정) 오퍼레이션은 한 단위의 오퍼레이션이다, 즉 (1) 프로세서는 상기 오퍼레이션이 완료될 때까지 인터럽트하지 않을 것이고, (2) 멀티프로세서 환경에서, 오퍼레이션이 완료될 때까지 다른 프로세서는 LOCK 비트를 액세스할 수 없을 것이다. 일부 실시예에서, 이러한 테스트 및 설정 오퍼레이션은 단계(1-0 내지 1-3)와 동시에 수행된다. 다른 실시예에서, 이러한 테스트 및 설정 오퍼레이션은 단계(1-0 내지 1-3)후와 LOCKADDR 레지스터중의 아무것도 로크될 오브젝트의 어드레스를 포함하지 않은 경우에만 수행된다.
만일 어떠한 LOCKADDR 레지스터도 로크될 오브젝트의 어드레스를 포함하지 않고(단계(2)), LOCK 비트가 테스트 및 설정 오퍼레이션전에 설정된 경우(단계(2a)), 프로세서(110)는 트랩 LockBusyTrap을 발생시킨다.
LockBusyTrap을 위한 트랩 핸들러는 만일 현재 스레드가 오브젝트를 위한 로크를 유지하고 있는가를 보기 위해 현재 스레드의 테이블(310)을 탐색한다. 만일 오브젝트 어드레스가 테이블(310)의 엔트리중의 하나에서 mLOCKADDR에 기억된 어드레스와 동일한 경우, 대응하는 mLOCKCOUNT는 트랩 핸들러에 의해 인크리먼트된다.
또한, 일부 실시예에서, 트랩 핸들러는 엔트리를 레지스터쌍 LOCKADDR/LOCKCOUNT에 위치시킬수도 있다. 이것은 만일 스레드에 의해 발생될 다음 로크 또는 언로크 명령이 스레드가 가장 최근에 로크 명령을 발생시킨 오브젝트를 위한 것과 유사한 경우가 바람직하다. 만일 트랩 핸들러가 엔트리를 레지스터 쌍으로 위치시키기를 원하지만 모든 레지스터쌍이 다른 로크에 의해 이용되는 경우, 트랩 핸들러는 레지스터 쌍을 테이블(310)에 기록하므로써 레지스터 쌍들중의 하나를 비워둔다(상기한 바와 같이 LOCKCOUNT 레지스터는 만일 mLOCKCOUNT가 LOCKCOUNT보다 긴 경우 mLOCKCOUNT LSBs에 기록된다).
만일 현재 스레드가 로크를 유지하고 있지 않고 따라서 오브젝트 어드레스가 대응하는 테이블(310)내 임의의 메모리 위치 mLOCKADDR와 매치하지 않는 경우, 트랩 핸들러는 오브젝트 헤더(도 2)내 WANT 비트를 설정하고, 이 로크를 받아들이기를 기다리는 스레드의 큐에 스레드를 위치시킨다.
이제 다시 실행 장치(136)에 의한 로크 명령의 실행을 설명한다. 만일 오브젝트의 LOCK 비트가 테스트 및 설정 오퍼레이션전에 설정되지 않은 경우, 단계(2b-0 내지 2b-3)이 실행된다. 각각의 단계(2b-i(i=0 내지 3))에서, 각각의 비교기는 레지스터 LOCKADDRi와 제로를 비교한다. 이러한 비교는 단계(1-0 내지 1-3 및 2)의 비교와 동시에 수행된다. 만일 LOCKADDR0=0(단계(2b-0))인 경우, 레지스터쌍 LOCKADDR0/LOCKCOUNT0은 사용되지 않는다. 레지스터 LOCKADDR0에는 로크되는 오브젝트의 어드레스가 기록된다(단계(2b-0a)). 레지스터 LOCKCOUNT0은 1로 설정된다(단계(2b-0b)).
만일 LOCKADDR0이 0이 아니지만 LOCKADDR1=1이라면, 레지스터 LOCKADDR1에는 로크될 오브젝트의 어드레스가 기록되고, 레지스터 LOCKCOUNT1은 1로 설정된다(단계(2b-1a,2b-1b)). 만일 LOCKADDR0 및 LOCKADDR1이 0이 아니지만 LOCKADDR2=0이라면, LOCKADDR2에는 로크될 오브젝트의 어드레스가 쓰여지고, 레지스터 LOCKCOUNT2는 1로 설정된다(단계(2b-2a,2b-2b)). 만일 LOCKADDR0, LOCKADDR1, 및 LOCKADDR2이 0이 아니지만 LOCKADDR3=0이라면, LOCKADDR3에는 로크될 오브젝트의 어드레스가 쓰여지고, 레지스터 LOCKCOUNT3는 1로 설정된다(단계(2b-3a,2b-3b)).
만일 어떠한 LOCKADDR 레지스터도 0과 같지 않다면, 트랩 NoLockAddrRegsTrap이 발생된다(단계(2c)). 일부 실시예에서, 이러한 트랩을 위한 트랩 핸들러는 현재 스레드의 테이블(310)내 프리 엔트리를 찾거나 생성한다. 트랩 핸들러는 그 엔트리의 위치 mLOCKADDR로 로크될 오브젝트의 어드레스를 기록하고, 대응하는 mLOCKCOUNT를 1로 설정한다. 또한, 트랩 핸들러는 테이블 엔트리를 LOCKADDR/LOCKCOUNT 레지스터 쌍으로 위치시킬 수도 있다. 레지스터쌍의 오래된 내용은 레지스터쌍이 기록되기전에 스레드 테이블(310)내에 기억된다.
부록 B는 언로크 명령을 위한 의사코드를 나타내고 있다. 단계(1-0 내지 1-3)에서, LOCKADDR 레지스터는 언로크될 오브젝트의 어드레스와 동시에 비교된다. 만일 매치가 발생하면, 이것은 현재 스레드가 로크를 유지하고, 대응하는 LOCKCOUNT 레지스터가 디크리먼터에 의해 디크리먼트되며(단계(1-0a,1-1a,1-2a,1-3a), 제로와 비교된다(단계(1-0b,1-1b,1-2b,1-3b)는 것을 나타내는 것이다. 만일 LOCKCOUNT 레지스터가 디크리먼트후 0이 되면, 트랩 LockCountZeroDecrementTrap이 발생된다. 상기한 바와 같이, 일부 실시예에서, 테이블(310)내 위치 mLOCKCOUNT는 LOCKCOUNT보다 길다. 그러한 일부 실시예에서, LockCountZeroDecrementTrap를 위한 트랩 핸들러는 그 mLOCKADDR이 언로크되는 오브젝트의 어드레스를 기억하는 엔트리를 위해 대응하는 테이블(310)을 탐색한다. 만일 그러한 엔트리가 발견되면, 트랩 핸들러는 0까지 디크리먼트된 LOCKCOUNT 레지스터에 대응하는 mLOCKCOUNT 위치를 점검한다. 만일 그 mLOCKCOUNT 위치가 LOCKCOUNT 레지스터에 기록되지 않은 MSBs내에 "1"을 갖는 경우, 오브젝트는 스레드에 의해 로크되어 있다. mLOCKCOUNT 메모리 위치에서, MSBs에 의해 형성된 필드가 디크리먼트되고, LSBs는 11...1(모든 1들)로 설정되며, LOCKCOUNT 레지스터에 기록된다.
만일 mLOCKCOUNT MSBs가 모두 0들이거나, 언로크되는 오브젝트의 어드레스를 보유하는 mLOCKADDR를 갖는 엔트리가 없다면, 트랩 핸들러는 다른 스레드에서 유효하게 하는 로크를 해제한다. 로크를 해제하는 방법은 좀더 상세하게 후술되어 있다.
만일 mLOCKCOUNT 위치가 LOCKCOUNT 레지스터보다 길지 않다면, 트랩 핸들러는 로크가 해제될 것인지 여부를 결정하기 위해 mLOCKCOUNT 위치를 점검할 필요가 없다.
다음의 오퍼레이션은 로크를 해제하는 단계와 관련되어 있다. 트랩 핸들러는 오브젝트 헤더(220H)의 WANT 비트를 검사한다. 만일 WANT 비트가 설정된 경우, 또다른 스레드가 이 로크에서 블로크된다. 트랩 핸들러는 그러한 스레드중의 하나를 선택하고, 그 상태를 실행가능하게 설정하며, 이 스레드에 로크를 건다. 만일 매치한다면, 이것은 현재 스레드가 로크를 유지하고 있고, 대응하는 LOCKCOUNT 레지스터가 디크리먼터에 의해 디크리먼트되며(단계(1-0a,1-1a,1-2a,1-3a)), 제로와 비교된다(단계(1-0b,1-1b,1-2b,1-3b)). 만일 LOCKCOUNT 레지스터가 디크리먼트후 0이 된다면, 트랩 LockCountZeroDecrementTrap이 발생된다. 상기한 바와 같이, 일부 실시예에서, 테이블내 위치 mLOCKCOUNT는 LOCKCOUNT 레지스터보다 길다. 그러한 일부 실시예에서, LockCountZeroDecrementTrap을 위한 트랩 핸들러는 그 mLOCKADDR가 언로크되는 오브젝트의 어드레스를 기억하는 엔트리를 위한 대응하는 테이블(310)을 탐색한다. 만일 그러한 엔트리가 발견되면, 트랩 핸들러는 0까지 디크리먼트된 LOCKCOUNT 레지스터에 대응하는 mLOCKCOUNT위치를 점검한다. 만일 그 mLOCKCOUNT 위치가 LOCKCOUNT 레지스터에 기록되지 않은 MSBs내에 "1"을 갖는 경우, 오브젝트는 스레드에 의해 로크된 채로 있는다. mLOCKCOUNT 메모리 위치에서, MSBs에 의해 형성된 필드는 디크리먼트되고, LSBs는 11...1(모두 1들)로 설정되며, LOCKCOUNT 레지스터에 기록된다.
만일 mLOCKCOUNT MSBs가 모두 0들이거나, 또는 만일 언로크되는 오브젝트의 어드레스를 보유하고 있는 mLOCKADDR를 갖는 엔트리가 없다면, 트랩 핸들러는 다른 스레드를 유효하게 하는 로크를 해제한다. 로크를 해제하는 단계는 좀더 상세하게 후술된다.
만일 mLOCKCOUNT 위치가 LOCKCOUNT 레지스터보다 길지 않은 경우, 트랩 핸들러는 로크가 해제될 것인지 여부를 결정하기 위해 mLOCKCOUNT 위치를 점검할 필요가 없다.
로크를 해제하는 단계는 다음의 오퍼레이션과 관련된다. 트랩 핸들러는 오브젝트 헤더(220H)의 WANT 비트를 검사한다. 만일 WANT 비트가 설정되어 있다면, 또다른 스레드는 이 로크에서 블로크된다. 트랩 핸들러는 그러한 스레드중의 하나를 선택하고, 그 상태를 실행가능하게 설정하며, 이 스레드에 로크를 건다. 특히, 트랩 핸들러는 LOCKCOUNT 레지스터에 1의 카운트를 기록한다. 만일 대응하는 쌍 mLOCKADDR/mLOCKCOUNT이 있을 경우, 트랩 핸들러는 mLOCKCOUNT 위치에 1을 기록한다. 대신, 일부 실시예에서, 트랩 핸들러는 mLOCKADDR/mLOCKCOUNT 쌍을 할당해제하기 위해 mLOCKADDR 위치에 0을 기록한다. 또한, 만일 로크를 수신하는 스레드가 로크상에서 블로크된 스레드만 있을 경우, 트랩 핸들러는 WANT 비트를 재설정한다.
만일 로크상에서 블로크된 스레드가 없을 경우, 트랩 핸들러는 (a) 대응하는 LOCKADDR 레지스터 및 (b) 하나가 존재한다면 대응하는 mLOCKADDR 위치에 제로를 기록한다. 또한, 트랩 핸들러는 헤더(220H)내 LOCK 비트를 리셋한다. 또한, 만일 현재 스레드의 테이블(310)이 레지스터가 유효하지 않기 때문에 LOCKADDR/LOCKCOUNT 레지스터에 기록될 수 없는 비어있지 않은 엔트리를 포함하는 경우, 트랩 핸들러는 로크 해제 오퍼레이션에 의해 비어있는 LOCKADDR/LOCKCOUNT 레지스터 쌍에 엔트리중의 하나를 위치시킨다.
만일 LOCKADDR 레지스터중의 어떤 것도 언로크될 오브젝트의 어드레스를 보유하는 경우(단계(2)), LockReleaseTrap이 발생된다. 관련된 트랩 핸들러는 언로크될 오브젝트의 어드레스를 위한 현재 스레드 테이블(310)의 mLOCKADDR 위치를 탐색한다. 만일 매치가 발생되면, 대응하는 위치 mLOCKCOUNT는 트랩 핸들러에 의해 디크리먼트된다. 만일 mLOCKCOUNT가 0이 되는 경우, 로크가 해제된다. 로크를 해제하기 위해, 트랩 핸들러는 트랩 LockCountZeroDecrementTrap에서 상기한 바와 유사한 오퍼레이션을 수행한다. 특히, 만일 WANT 비트가 설정되는 경우, 트랩 핸들러는 로크상에서 또다른 스레드 블로크를 발견하고 그 스레드 상태를 실행가능하게 설정한다. 트랩 핸들러는 대응하는 위치 mLOCKCOUNT를 1로 설정한다. 일부 실시예에서, 트랩 핸들러는 mLOCKADDR/mLOCKCOUNT 엔트리를 LOCKADDR/LOCKCOUNT 레지스터쌍에 위치시킨다. 만일 로크를 수신한 스레드가 로크상에서 블로크된 스레드만 있다면, 트랩 핸들러는 WANT 비트를 리셋한다. 만일 로크상에서 블로크된 스레드가 없다면(WANT 비트가 0), 트랩 핸들러는 mLOCKADDR 위치에 제로를 기록하고, 오브젝트 헤더(220H)내 LOCK 비트를 리셋한다.
만일 현재 스레드의 테이블(310)내 메모리 위치 mLOCKADDR중 어떤 것도 언로크될 오브젝트의 어드레스를 보유하지 않는 경우, 트랩 핸들러는 예외 IllegalMonitorStateException를 발생시킨다. 일부 실시예에서, 이러한 예외는 JavaTM 스로우(throw)가 된다. 특히, 일부 실시예에서, 프로세서(110)는 JavaTM Virtual Machine 언어 명령(Java 바이트코드로 공지됨)을 실행한다. 예를 들어 본 명세서에서 참조에 의해 구체화된 T.Lindholm과 F.Yellin의 "The JavaTM Virtual Machine Specification"(1997)에 Java Virtual Machine 언어가 기재되어 있다.
프로세서(110)는 다음의 다수의 공통 상황에서의 고속 로크 및 언로크 방법을 제공한다: 로크에서의 경쟁이 없는 경우, 및 오브젝트 로크가 해제되기전에 동일한 오브젝트상에서 다수의 로크 오퍼레이션을 수행하는 경우. 특히, 로크 명령이 발생될 때, 다수의 경우에 오브젝트는 또다른 스레드에 의해 로크되지 않는다(즉, 경쟁이 전혀 발생하지 않는다). 만일 오브젝트가 이제 로크 명령을 발생시킨 동일한 스레드에 의해 이미 로크되었다면, 다수의 경우에서 스레드가 동시에 4개 이상의 로크를 유지하지 않고, 상기 스레드에서의 모든 로크된 오브젝트 어드레스는 LOCKADDR 레지스터내에 있기 때문에 오브젝트의 어드레스는 이미 LOCKADDR 레지스터에 있게 된다. 만일 로크된 오브젝트 어드레스가 모두 LOCKADDR 레지스터내에 있지는 않더라도, 로크 명령에 의해 지정된 오브젝트의 어드레스가 LOCKADDR 레지스터내에 있을 가능성이 있다. 그러한 다수의 경우에서, 로크 오퍼레이션은 대응하는 LOCKCOUNT 레지스터를 인크리먼트하기를 요구하고(부록 A, 단계(1-ia, i=0,1,2,3), 이것은 다수의 실시예에서 고속 오퍼레이션이 된다. 만일 인크리먼트로 인한 오버플로우가 발생하지 않는다면, 어떠한 트랩도 발생되지 않을 것이다.
레지스터 쌍 LOCKADDR/LOCKCOUNT중의 하나가 사용되지 않는다면, 오브젝트가 임의의 스레드(로크 명령에 의해 발생된 스레드 포함)에 의해 로크되지 않았을 때 또한 로크가 빨라진다. 그러한 경우, 오브젝트는 단계(2b-0 내지 2b-3)(부록 A)중의 하나에서 로크된다. 역시, 트랩은 전혀 발생되지 않는다.
유사하게, 언로크 명령에서, 다수의 경우에, 언로크될 오브젝트의 어드레스는 LOCKADDR 레지스터중의 하나내에 있을 것이다. 만일 대응하는 LOCKCOUNT 레지스터가 비제로값까지 디크리먼트되는 경우, 트랩은 발생되지 않는다.
일부 실시예에서, 프로세서(110)는 Sun Microsystems(Mountain View, California)에 의해 그 제품이 생산된 "picoJavaⅠ" 형태의 마이크로프로세서이다. 이러한 마이크로프로세서는 Java Virtual Machine 명령을 실행시킨다. 로크 명령은 Java Virtual Machine 명령세트의 "monitorenter" 명령이거나, 프로세서 "picoJavaⅠ"의 "enter_sync_method" 명령이다. "enter_sync_method" 명령은 "monitorenter"와 유사하지만, "enter_sync_method" 명령은 파라메터로서 오브젝트보다는 방법에 대한 레퍼런스를 취한다. "enter_sync_method"는 상기 방법을 위한 오브젝트를 위한 수신 오브젝트를 로크하고, 상기 방법을 실시한다. 언로크 명령은 Java Virtual Machine 명령 세트의 "monitorexit" 명령이거나, 앞선 "enter_sync_method" 명령에서 레퍼런스된 방법으로부터의 리턴 명령이다.
일부 실시예에서, 프로세서(110)는 4개 이상 또는 이하의 LOCKADDR/LOCKCOUNT 레지스터 쌍을 포함한다.
일부 실시예에서, 레지스터(144)는 도 4에 도시된 바와 같은 레지스터 3쌍을 포함한다. 각각의 3쌍에서, 레지스터 THREAD_ID는 레지스터 쌍 LOCKADDR/LOCKCOUNT에 레코딩된 로크를 보유하는 스레드를 식별한다. 로크 또는 언로크 명령이 발생될 때, 실행장치(136)는 레지스터 THREAD_ID가 현재 스레드의 ID를 보유하기 때문에 그들 LOCKADDR/LOCKCOUNT 쌍만을 검사한다. 다른 측면에서, 로크 및 언로크 명령의 실행은 도 2의 경우와 유사하다. 도 4의 구조는 로크된 오브젝트의 어드레스 및 다른 스레드를 위한 레지스터(144)내 로크 카운트를 동시에 유지하는 것을 용이하게 한다. 도 4의 구조체가 사용된 일부 실시예에서, OS는 다른 스레드가 실행을 위해 스케쥴되었을 때 레지스터(144)를 다시 로드하지 않는다. OS는 도 3에 도시된 바와 같은 각각의 스레드를 위한 테이블(310)을 유지한다. 레지스터 3쌍이 비어있어야 할 때, 대응하는 LOCKADDR/LOCKCOUNT 값은 대응하는 테이블(310)에 기록된다. 테이블 엔트리가 레지스터 쌍 LOCKADDR/LOCKCOUNT에 위치되는 경우, 대응하는 레지스터 THREAD_ID에는 대응하는 스레드의 ID가 기록된다.
도 1-4의 프로세서는 Java Virtual Machine 로크 및 언로크 명령 "monitorenter"와 "monitorexit"의 효율적인 구현에 적당하다. Java에서의 오브젝트 모니터와 관련된 카운터는 레지스터 LOCKCOUNT를 이용하여 구현될 수 있다.
일부 실시예에서, 레지스터 LOCKCOUNT 및 위치 mLOCKCOUNT는 생략된다. 프로세서는 로크 카운트의 트랙을 유지하지 않고, 프로세서는 로크에 대응하는 임의의 언로크 명령상의 로크를 해제한다. 프로세서 오퍼레이션은 부록 A 및 부록 B와 관련하여 상기한 오퍼레이션과 유사하다. 그러나, 부록 A에서, 단계(1-0 내지 1-3b)는 생략된다. 단계(2b-0b,2b-1b,2b-2b,2b-3b)(LOCKCOUNT 오퍼레이션) 또한 생략된다. 부록 B에서, 단계(1-0a)가 생략되고, 단계(1-0b)에서 트랩 LockCountZeroDecrementTrap은 무조건적으로 발생된다. 동일한 것이 단계(1-1a과 1-1b, 1-2a과 1-2b, 1-3a과 1-3b)에 적용된다.
일부 실시예에서, 각각의 LOCKCOUNT 레지스터는 1비트 길이이고, 프로세서는 로크에 대응하는 임의의 언로크 명령상의 로크를 해제한다.
상기한 실시예는 본 발명을 설명하고 있지만 제한하지는 않는다. 본 발명은 임의의 특정한 프로세서 구조, 캐시 또는 메모리의 존재 또는 구조, 또는 임의의 레지스터 또는 메모리 위치내 비트수에 의해 제한되지 않는다. 본 발명은 로크되거나 언로크될 수 있는 임의의 특정한 타입의 오브젝트에 제한되지 않는다. 오브젝트는 데이터, 임계 코드 섹션, 하드웨어, 또는 상기의 임의의 결합과 같은 자원을 포함하는 임의의 컴퓨터 자원을 나타낼 수 있다. 일부 실시예는 로크 및 언로크 오퍼레이션을 위한 컴퓨터 자원을 나타내기 위해 제공된 오브젝트를 생성한다. 상기한 실시예에서 사용되지 않은 레지스터 쌍 LOCKADDR/LOCKCOUNT가 LOCKADDR 레지스터에서 제로로 표시되는 반면, 일부 실시예에서 사용되지 않은 레지스터 쌍은 LOCKADDR 레지스터내에서 일부 비제로값으로 식별되거나, 또는 LOCKCOUNT 레지스터내에서 일부 값에 의해, 또는 도 4의 실시예에서 THREAD_ID 레지스터내 일부 값에 의해, 또는 LOCKADDR/LOCKCOUNT 레지스터쌍내 및/또는 LOCKADDR/LOCKCOUNT/THREAD_ID 레지스터중의 임의의 2 또는 3개내 값들의 결합에 의해, 또는 분리된 비트에 의해 식별된다. 사용되지 않은 mLOCKADDR/mLOCKCOUNT 위치에서 유사한 기술이 가능하다. 일부 실시예에서, 트랩 핸들러에 의해 수행된 바와 같은 상기한 오퍼레이션 모두 또는 일부는 소프트웨어대신 하드웨어에 의해 수행된다. 일부 실시예에서, 하드웨어에 의해 수행된 바와 같은 상기한 일부 오퍼레이션은 하드웨어 대신 소프트웨어에 의해 수행된다. 본 발명은 바이트 어드레스인 어드레스에 제한되지 않는다. 첨부된 청구의 범위에 의해 한정된 바와 같은, 본 발명의 범주내에서 다른 실시예 및 변경이 있을 수 있다.
부록 A
로크 명령
1-0. if (LOCKADDR0 == 로크될 오브젝트의 주소)
{
1-0a. LOCKCOUNT0++;
1-0b. if (LOCKCOUNT0 == 0) /* LOCKCOUNT0
overflowed*/
LockCountOverflowIncrementTrap;
}
1-1. if (LOCKADDR1 == 로크될 오브젝트의 주소)
{
1-1a. LOCKCOUNT1++;
1-1b. if (LOCKCOUNT1 == 0) /* LOCKCOUNT1
overflowed*/
LockCountOverflowIncrementTrap;
}
1-2. if (LOCKADDR2 == 로크될 오브젝트의 주소)
{
1-2a. LOCKCOUNT2++;
1-2b. if (LOCKCOUNT2 == 0) /* LOCKCOUNT2
overflowed*/
LockCountOverflowIncrementTrap;
}
1-3. if (LOCKADDR3 == 로크될 오브젝트의 주소)
{
1-3a. LOCKCOUNT3++;
1-3b. if (LOCKCOUNT3 == 0) /* LOCKCOUNT3
overflowed*/
LockCountOverflowIncrementTrap;
}
2. if (LOCKADDR0, LOCKADDR1, LOCKADDR2, LOCKADDR3중의 어느 것도 로크
될 오브젝트의 어드레스와 동일하지 않음)
{
2a. 오브젝트 헤더내 LOCK 비트를 테스트하고 LOCK 비트를 1로 설정
(이 테스트 및 설정 오퍼레이션은 한 단위의 오퍼레이션이다.)
if (테스트 및 설정 오퍼레이션전에 LOCK 비트 설정됨)
LockBusyTrap;
2b-0. else if (LOCKADDR0 ==0) /* LOCKADDR0 unused
*/
2b-0a. LOCKADDR0 = 로크될 오브젝트의 주소;
2b-0b. LOCKCOUNT0 = 1;
}
2b-1. else if (LOCKADDR1 ==0) /* LOCKADDR1 unused
*/
2b-1a. LOCKADDR1 = 로크될 오브젝트의 주소;
2b-1b. LOCKCOUNT1 = 1;
}
2b-2. else if (LOCKADDR2 ==0) /* LOCKADDR2 unused
*/
2b-2a. LOCKADDR2 = 로크될 오브젝트의 주소;
2b-2b. LOCKCOUNT2 = 1;
}
2b-3. else if (LOCKADDR3 ==0) /* LOCKADDR3 unused
*/
2b-3a. LOCKADDR3 = 로크될 오브젝트의 주소;
2b-3b. LOCKCOUNT3 = 1;
}
2c. else NoLockAddrRegsTrap;
}
부록 B
언로크 명령
1-0. if (LOCKADDR0 == 언로크될 오브젝트의 주소)
{
1-0a. LOCKCOUNT0--;
1-0b. if (LOCKCOUNT0 == 0)
LockCountZeroDecrementTrap;
}
1-1. if (LOCKADDR1 == 언로크될 오브젝트의 주소)
{
1-1a. LOCKCOUNT1--;
1-1b. if (LOCKCOUNT1 == 0)
LockCountZeroDecrementTrap;
}
1-2. if (LOCKADDR2 == 언로크될 오브젝트의 주소)
{
1-2a. LOCKCOUNT2--;
1-2b. if (LOCKCOUNT2 == 0)
LockCountZeroDecrementTrap;
}
1-3. if (LOCKADDR3 == 언로크될 오브젝트의 주소)
{
1-3a. LOCKCOUNT3--;
1-3b. if (LOCKCOUNT3 == 0)
LockCountZeroDecrementTrap;
}
2. if (LOCKADDR0, LOCKADDR1, LOCKADDR2, LOCKADDR3중의 어느 것도 언로
크될 오브젝트의 어드레스와 동일하지 않음)
LockReleaseTrap

Claims (16)

  1. 로크된 컴퓨터 자원을 식별하는 값을 보유하는 하나 이상의 레지스터(R1)(LOCKADDR); 및
    컴퓨터 자원을 로크하기 위한 로크 오퍼레이션, 컴퓨터 자원을 언로크하기 위한 언로크 오퍼레이션, 또는 로크 및 언로크 오퍼레이션을 모두 수행하는 회로로 이루어지고,
    각각의 레지스터(R1)는 로크 오퍼레이션이 상기 컴퓨터 프로세서에 의해 실행되고, 컴퓨터 자원에 대한 로크를 유지할 수 있는 컴퓨터 엔티티에 의해 수행되는 경우에만 로크 오퍼레이션에 의해 변경가능하며,
    상기 회로는 컴퓨터 자원을 식별하는 값(V1)을 수신하고, 상기 자원이 프로세서에 의해 실행되는 컴퓨터 엔티티에 의해 로크된다는 표시인 값(V1)을 레지스터(R1)가 보유하는지 여부를 결정하는 여부를 결정하는 것을 특징으로 하는 컴퓨터 프로세서(110).
  2. 제 1 항에 있어서,
    레지스터(R1)는 컴퓨터 프로세서의 명령 실행장치(136)의 일부인 것을 특징으로 하는 컴퓨터 프로세서.
  3. 제 1 항 또는 제 2 항에 있어서,
    레지스터(R1)에 의해 식별된 로크된 컴퓨터 자원과 관련된 카운트를 나타내는 값을 보유하는 하나 이상의 레지스터(R2)(LOCKCOUNT)를 더 구비하고,
    각각의 카운트는 자원에 대해 발생된, 그러나 대응하는 언로크 명령이 발생하지 않은 로크 명령의 카운트이며,
    적어도 하나의 로크 또는 언로크 오퍼레이션에서, 회로는 만일 레지스터(R1)가 자원이 로크된 것의 표시로서의 값(V1)을 보유하는 경우 레지스터(R2)를 변경하는 것을 특징으로 하는 컴퓨터 프로세서.
  4. 제 3 항에 있어서,
    레지스터(R2)는 컴퓨터 프로세서의 명령 실행장치(136)의 일부인 것을 특징으로 하는 컴퓨터 프로세서.
  5. 제 3 항 또는 제 4 항에 있어서,
    각각의 레지스터(R2)는 대응하는 소정 레지스터(R1)와 관련된 카운트를 보유하는 것을 특징으로 하는 컴퓨터 프로세서.
  6. 제 1 항 내지 제 5 항 중 어느 한 항에 있어서,
    각각의 레지스터(R1)에서, 대응하는 레지스터(R1)내 값에 의해 식별된 자원에 대한 로크를 유지하는 실행가능한 컴퓨터 엔티티를 식별하는 레지스터(R3)(THREAD_ID)를 더 구비하고,
    레지스터(R1)가 값(V1)을 보유하는가를 결정하는 회로 결정단계는, 컴퓨터 프로세서에 의해 식별되는 컴퓨터 엔티티를 식별하는 임의의 레지스터(R3)에서 대응하는 레지스터(R1)가 값(V1)을 보유하는지 여부를 결정하는 회로 결정단계를 구비하는 것을 특징으로 하는 컴퓨터 프로세서.
  7. 프로세서에 의해 실행되는 컴퓨터 엔티티에 의해 로크된 자원을 식별하는 값을 기억하는 하나 이상의 로크 레지스터(R1)로 이루어지는 컴퓨터 프로세서를 작동하는 프로세스에 있어서,
    컴퓨터 프로세서가 하나의 컴퓨터 엔티티에서 다른 컴퓨터 엔티티로 스위치하는 단계; 및
    프로세서가 하나의 컴퓨터 엔티티에서 다른 컴퓨터 엔티티로 스위치할 때, 프로세서가 스위치하는 컴퓨터 엔티티에 의해 로크된 자원을 식별하는 값을 하나 이상의 레지스터(R1)에 로드하는 단계로 이루어지는 것을 특징으로 하는 프로세스.
  8. 제 7 항에 있어서,
    프로세서는 각각의 레지스터(R1)에서, 대응하는 레지스터(R1)에 의해 식별된 자원과 관련된 카운트를 보유하는 대응 레지스터(R2)를 더 구비하고,
    카운트는 대응하는 언로크 명령이 발생되지 않은 로크 명령의 카운트이며,
    프로세서가 하나의 컴퓨터 엔티티에서 다른 컴퓨터 엔티티로 스위치할 때, 각각의 레지스터(R2)에는 대응하는 레지스터(R1)로 로드되는 값에 대응하는 카운트가 로드되고, 카운트는 프로세서가 스위치하고 있는 컴퓨터 엔티티와 관련되는 것을 특징으로 하는 프로세스.
  9. 컴퓨터 오브젝트 데이터(220)를 기억하는 컴퓨터 판독가능한 기억매체에 있어서,
    상기 오브젝트 데이터는 오브젝트 데이터의 일부(230)의 어드레스를 식별하는 정보를 기억하는 필드(220H)로 이루어지고, 상기 오브젝트 데이터의 일부는 2바이트 한계로 기억되며, 상기 필드는 컴퓨터 어드레스의 크기를 갖지만 상기 오브젝트 데이터의 일부의 어드레스를 기억하기 위해 상기 필드의 전체 비트보다 적은 수의 비트가 사용되도록 오브젝트 데이터의 일부의 어드레스의 전체 비트보다 적은 비트를 기억하고,
    컴퓨터 판독가능한 기억매체는 오브젝트 데이터를 액세스하는 하나 이상의 컴퓨터 명령을 구비하며, 오브젝트 데이터의 일부의 어드레스를 기억하기 위해 사용되지 않은 필드의 하나 이상의 비트(L)는 오브젝트가 로크되는지 여부를 나타내는 컴퓨터 명령에 의해 사용되는 것을 특징으로 하는 컴퓨터 판독가능한 기억매체.
  10. 제 9 항에 있어서,
    오브젝트 데이터의 일부는 4바이트 한계로 기억되고, 상기 필드는 오브젝트 데이터의 일부의 어드레스를 기억하기 위해 사용되지 않은 적어도 2비트(W,L)를 가지며, 오브젝트 데이터의 일부의 어드레스를 기억하기 위해 사용되지 않은 필드의 하나 이상의 비트는 컴퓨터 엔티티가 오브젝트에 대한 로크를 받아들이기를 원하는지 여부를 나타내는 컴퓨터 명령에 의해 사용될 하나의 비트(W)를 포함하는 것을 특징으로 하는 컴퓨터 판독가능한 기억매체.
  11. 제 9 항 또는 제 10 항에 있어서,
    상기 컴퓨터 판독가능한 기억매체를 액세스하고 상기 컴퓨터 명령을 실행시키기 위해 작동가능한 컴퓨터 프로세서와 협력하는 것을 특징으로 하는 컴퓨터 판독가능한 기억매체.
  12. 삭제
  13. 삭제
  14. 삭제
  15. 삭제
  16. 삭제
KR10-1999-7006607A 1997-01-23 1997-01-23 컴퓨터 자원의 로크방법 및 장치 Expired - Lifetime KR100470555B1 (ko)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US1997/001217 WO1998033119A1 (en) 1997-01-23 1997-01-23 Locking of computer resources

Publications (2)

Publication Number Publication Date
KR20000070374A KR20000070374A (ko) 2000-11-25
KR100470555B1 true KR100470555B1 (ko) 2005-03-07

Family

ID=22260287

Family Applications (1)

Application Number Title Priority Date Filing Date
KR10-1999-7006607A Expired - Lifetime KR100470555B1 (ko) 1997-01-23 1997-01-23 컴퓨터 자원의 로크방법 및 장치

Country Status (5)

Country Link
EP (1) EP0954780B1 (ko)
JP (1) JP4196414B2 (ko)
KR (1) KR100470555B1 (ko)
DE (1) DE69711927D1 (ko)
WO (1) WO1998033119A1 (ko)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2784478B1 (fr) 1998-10-09 2000-11-17 Bull Sa Architecture de verrou pour grand systeme
DE19903599A1 (de) * 1999-01-29 2000-08-03 Siemens Ag Verfahren zum gesicherten Zugriff auf zumindest eine Variable in einem präemptiv Multitasking-gesteuerten Prozessorsystem
US6792601B1 (en) 2000-05-18 2004-09-14 International Business Machines Corporation Multiple mode object locking method and system
US6684398B2 (en) 2000-05-31 2004-01-27 Sun Microsystems, Inc. Monitor entry and exit for a speculative thread during space and time dimensional execution
US6735760B1 (en) 2000-11-08 2004-05-11 Sun Microsystems, Inc. Relaxed lock protocol
FR2829848A1 (fr) * 2001-09-20 2003-03-21 Cp8 Procede de gestion d'acces a des ressources partagees dans un systeme embarque et systeme embarque pour la mise en oeuvre d'un tel procede
GB2427045B (en) * 2005-06-06 2007-11-21 Transitive Ltd Method and apparatus for converting program code with access coordination for a shared resource
CN119225811B (zh) * 2024-09-12 2025-07-25 上海壁仞科技股份有限公司 一种寄存器溢出优化方法、设备、存储介质及程序产品

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5261108A (en) * 1988-10-08 1993-11-09 Nec Corporation Multiprocessor communications register providing complete access in a full access mode, and mapped access in a partial access mode

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4435766A (en) * 1981-06-16 1984-03-06 International Business Machines Corporation Nested resource control using locking and unlocking routines with use counter for plural processes

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5261108A (en) * 1988-10-08 1993-11-09 Nec Corporation Multiprocessor communications register providing complete access in a full access mode, and mapped access in a partial access mode

Also Published As

Publication number Publication date
EP0954780A1 (en) 1999-11-10
WO1998033119A1 (en) 1998-07-30
KR20000070374A (ko) 2000-11-25
DE69711927D1 (de) 2002-05-16
EP0954780B1 (en) 2002-04-10
JP4196414B2 (ja) 2008-12-17
JP2001519937A (ja) 2001-10-23

Similar Documents

Publication Publication Date Title
US5968157A (en) Locking of computer resources
US6230230B1 (en) Elimination of traps and atomics in thread synchronization
EP0768608B1 (en) Maximal concurrent lookup cache for computing systems having a multi-threaded environment
US6411983B1 (en) Mechanism for managing the locking and unlocking of objects in Java
US5924098A (en) Method and apparatus for managing a linked-list data structure
US5727209A (en) Apparatus and method for achieving reduced overhead mutual-exclusion and maintaining coherency in a multiprocessor system utilizing execution history and thread monitoring
US5317739A (en) Method and apparatus for coupling data processing systems
US5442763A (en) System and method for preventing deadlock in multiprocessor multiple resource instructions
JP3575593B2 (ja) オブジェクトのロック管理方法及び装置
US5265245A (en) High concurrency in use manager
US6560627B1 (en) Mutual exclusion at the record level with priority inheritance for embedded systems using one semaphore
US7716192B2 (en) Concurrent, lock-free object copying
US6889269B2 (en) Non-blocking concurrent queues with direct node access by threads
US7117502B1 (en) Linked-list implementation of a data structure with concurrent non-blocking insert and remove operations
US6651146B1 (en) Method and apparatus for managing access contention to a linear list without the use of locks
US20040107227A1 (en) Method for efficient implementation of dynamic lock-free data structures with safe memory reclamation
US7571288B2 (en) Scalable rundown protection for object lifetime management
US20030140085A1 (en) Single-word lock-free reference counting
WO2003060705A2 (en) Lock-free implementation of dynamic-sized shared data structure
Michael Practical lock-free and wait-free LL/SC/VL implementations using 64-bit CAS
KR100470555B1 (ko) 컴퓨터 자원의 로크방법 및 장치
Moreno et al. On the implementation of memory reclamation methods in a lock-free hash trie design
US6513100B1 (en) System and method for fast referencing a reference counted item
Luchangco et al. On the uncontended complexity of consensus
US7334229B1 (en) Mutual exclusion at the record level with priority inheritance for embedded systems using one semaphore

Legal Events

Date Code Title Description
PA0105 International application

Patent event date: 19990722

Patent event code: PA01051R01D

Comment text: International Patent Application

PG1501 Laying open of application
A201 Request for examination
PA0201 Request for examination

Patent event code: PA02012R01D

Patent event date: 20011130

Comment text: Request for Examination of Application

E902 Notification of reason for refusal
PE0902 Notice of grounds for rejection

Comment text: Notification of reason for refusal

Patent event date: 20040315

Patent event code: PE09021S01D

E701 Decision to grant or registration of patent right
PE0701 Decision of registration

Patent event code: PE07011S01D

Comment text: Decision to Grant Registration

Patent event date: 20041119

GRNT Written decision to grant
PR0701 Registration of establishment

Comment text: Registration of Establishment

Patent event date: 20050128

Patent event code: PR07011E01D

PR1002 Payment of registration fee

Payment date: 20050131

End annual number: 3

Start annual number: 1

PG1601 Publication of registration
PR1001 Payment of annual fee

Payment date: 20080122

Start annual number: 4

End annual number: 4

PR1001 Payment of annual fee

Payment date: 20090123

Start annual number: 5

End annual number: 5

PR1001 Payment of annual fee

Payment date: 20100125

Start annual number: 6

End annual number: 6

PR1001 Payment of annual fee

Payment date: 20101222

Start annual number: 7

End annual number: 7

PR1001 Payment of annual fee

Payment date: 20120109

Start annual number: 8

End annual number: 8

FPAY Annual fee payment

Payment date: 20130107

Year of fee payment: 9

PR1001 Payment of annual fee

Payment date: 20130107

Start annual number: 9

End annual number: 9

FPAY Annual fee payment

Payment date: 20140106

Year of fee payment: 10

PR1001 Payment of annual fee

Payment date: 20140106

Start annual number: 10

End annual number: 10

FPAY Annual fee payment

Payment date: 20150106

Year of fee payment: 11

PR1001 Payment of annual fee

Payment date: 20150106

Start annual number: 11

End annual number: 11

FPAY Annual fee payment

Payment date: 20160104

Year of fee payment: 12

PR1001 Payment of annual fee

Payment date: 20160104

Start annual number: 12

End annual number: 12

EXPY Expiration of term
PC1801 Expiration of term

Termination date: 20170723

Termination category: Expiration of duration