KR20070108329A

KR20070108329A - 하드웨어 공유 시스템 및 방법

Info

Publication number: KR20070108329A
Application number: KR1020070042541A
Authority: KR
Inventors: 고칸 아브카로굴라리; 스티븐 엘. 피터슨
Original assignee: 엔비디아 코포레이션
Priority date: 2006-05-06
Filing date: 2007-05-02
Publication date: 2007-11-09
Also published as: TW200820083A; CN101078996A; US8726279B2; KR100902977B1; CN101078996B; US20070261053A1; TWI368877B

Abstract

본 발명은 다수의 스레드를 갖는 적어도 하나의 소프트웨어 프로세스에서 실행되는 컴퓨터 시스템에서 하드웨어 자원을 공유하기 위한 방법 및 시스템을 개시한다. 컴퓨터 시스템 내의 데이터 구조에는 lock_indicator가 제공된다. 요청 스레드로 되도록 정의된 스레드들 중 하나에 의해 하드웨어 자원을 이용하기 위한 요청을 수신한다. lock_indicator에 기초하여, 요청 스레드에 의한 이용을 위해 하드웨어 자원이 이용 가능한지를 결정한다. lock_indicator가 하드웨어 자원이 이용 가능한 것으로 지시하면, lock_indicator는 하드웨어 자원이 이용 가능하지 않음을 지시하는 대신 하드웨어 자원의 제어 하에 설정되고, go_indicator는 요청에 대한 하드웨어 자원의 이용이 현재 진행될 수 있음을 지시하도록 신호한다.

스레드, 소프트웨어, 컴퓨터, 하드웨어, 데이터 구조

Description

하드웨어 공유 시스템 및 방법{HARDWARE SHARING SYSTEM AND METHOD}

도 1a-b(배경 기술)는 최신 컴퓨터 시스템의 잠재적인 복잡성을 문체 양식으로 도시하는 블록도들로서, 도 1a는 단일의 메인 프로세서를 포함하는 단순한 컴퓨터 시스템을 도시하고, 도 1b는 다수의 메인 프로세서들을 포함하는 복잡한 컴퓨터 시스템을 도시한 도면.

도 2(배경 기술)는 통상의 소프트웨어 잠금(software locks)이 이용되는 방식(scheme)에서 실행 스레드가 하드웨어 자원의 이용을 취득하는 방법을 나타낸 의사 코드 목록(pseudo code listing).

도 3a-d(배경 기술)는 두 대표적인 경우들, 즉 실행 스레드가 아이들 하드웨어 자원(idle hardware resources)에 액세스하는 최상의 경우에 근접하는 가상의 상황, 및 최악의 경우에 근접하는 가상의 상황을 각각 도시한 일련의 타이밍도.

도 4는 본 발명에 따른 하드웨어 잠금 시스템이 최신 컴퓨터 시스템과 연관되는 방법을 도시한 개략적인 블록도.

도 5는 도 4의 본 발명의 하드웨어 잠금 시스템의 예시적인 실시예에서의 주요 데이터 구조들을 도시한 개략적인 블록도.

도 6a-g는 본 발명에 따른 하드웨어 잠금 시스템이 하드웨어 가속기(hardware accelerator)를 프로그램하는데 이용되는 프로세스를 도시하는 일련의 흐름도들로서, 도 6a는 전체 흐름도를 도시하고, 도 6b-d는 하드웨어에 의하여 수행되는 "원자적(atomic)" 단계들의 세부사항들을 도시하며, 도 6e-g는 소프트웨어에 의하여 수행되는 단계들의 세부사항들을 도시한 도면.

<도면의 주요 부분에 대한 부호의 설명>

12 : 컴퓨터 시스템

14 : SW 애스펙트

16 : HW 애스펙트

20 : 스레드

24 : 하드웨어 자원

26 : 다중채널 하드웨어 장치

본 발명은 일반적으로 전자 컴퓨터 및 디지털 데이터 처리 시스템에서의 입력 및 출력에 관한 것이며, 보다 구체적으로는, 이러한 시스템의 공유 자원으로의 액세스를 막기 위한 수단 또는 단계에 관한 것이다. 본 발명은 적어도 비동기 하드웨어 장치의 멀티 스레드된(multi threaded) 멀티 프로세서 공유를 위한 시스템을 개시한다.

최신 컴퓨터 시스템에서, 프로세서 또는 프로세서들 상에서 수행되는 소프트웨어 프로세스들(software processes:SW)이 다수의 실행 스레드를 사용하는 것이 점점 일반화되고 있다. 이들 실행 스레드는, 다수의 스레드가 동일한 프로세서 상에서 수행되는 경우에는 지각된 동시성(perceived concurrency)을 나타내며, 컴퓨터 시스템에 다수의 프로세스가 있는 경우에는 진정한 동시성(true concurrency)을 나타낼 수 있다.

또한, 최신 컴퓨터 시스템에서는, 직접 메모리 액세스(direct memory access:DMA) 채널, 내부 버퍼링 또는 내부 DMA 엔진을 지니는 주변장치, 및 전용 메모리 영역, 내부 버퍼로부터 동작하거나 또는 DMA를 사용하는 미디어 처리 구성요소와 같은 정교한 하드웨어 자원(HW)을 갖는 것이 점점 일반화되고 있다. 일부 하드웨어 자원은 또한 다중채널을 가질 수 있어, 동시에 수행될 수 있으면서 또한 관리될 필요가 있는 유효 하드웨어 자원의 수가 증가할 수 있다(다중채널 장치는 다수의 자원으로서 컴퓨터 시스템에 의해 유효하게 사용될 수 있기 때문에, 본 명세서에서는 "하드웨어 장치"와의 혼돈을 피하기 위해 각 채널에 대해 "하드웨어 자원"이라 한다).

컴퓨터 시스템의 하드웨어 자원은 종종 비동기로 되는 것이 바람직하며, 따라서 이 자원들을 관리하는 프로세서 또는 프로세서들은 원하는 태스크에 대해 각각을 프로그램하고, 다른 어떤 것을 계속하다가, 이후에 이전의 프로그램된 태스크로 복귀하여 그 결과를 얻을 수 있다. 이것이 진정한 병렬 처리(true parallelism)이다.

하드웨어 자원이 다수의 실행 스레드에 의해 사용될 때, 스레드의 동시성 속성에 상관없이, 한 번에 단 하나의 실행 스레드만이 하드웨어 자원을 사용할 수 있 도록 보장하기 위해 일부 메커니즘이 사용가능해야만 한다. 이것은 하드웨어 자원의 올바른 동작을 보장하고, 실행 스레드에 의해 얻어진 결과가 옳다는 것을 보증하기 위해 필요하다. 종래 기술의 접근방법이 소프트웨어 잠금(예를 들면, "mutex"라 종종 지칭되는, 소프트웨어 상호 배제(mutual exclusion) 잠금)에 기초하기 때문에, 이것은 종래 기술의 접근방법이 여전히 모자라는 바이다.

도 1a 및 도 1b(배경 기술)는 최신 컴퓨터가 얼마나 복잡한 시스템이 될 수 있는지에 대한 예를 문체양식으로 도시하는 블록도이다. 도 1a는 단일 메인 프로세서를 갖는 단순한 컴퓨터 시스템을 도시하고, 도 1b는 다수의 메인 프로세서들을 갖는 좀 더 복잡한 컴퓨터 시스템을 도시하고 있다. 운영 체제의 제어 하에서, 각 프로세서들은 (본 명세서에 직접 도시되지는 않은) 다수의 소프트웨어 프로세스들을 수행할 수 있다. 본 목적을 위해, 소프트웨어 프로세스들에 관해 높은 레벨에서는 특별히 관여하지는 않지만, "실행 스레드(threads of execution)"(TOE)라 칭하는 소프트웨어 프로세스들의 기본 부분들에 대해서는 관여한다. 스레드된 프로그램의 실행은 컴퓨터 분야의 많은 뛰어난 저서들에서 다루어지고 있기 때문에, 본 명세서에서는 단지 단일 소프트웨어 프로세스가 단일 스레드, 또는 다수의 스레드를 지닐 수 있으며, 이들 모두 전체적인 컴퓨터 시스템 내의 자원에 대해 경쟁 관계에 있을 수 있다는 것만을 주목한다. 특히, 컴퓨터 시스템의 실행 드레드는 하나 이상의 하드웨어 자원(HWR)을 비동기적으로 공유할 필요가 있을 수 있다.

도 1a를 다시 참조해보면, TOE #2는 실행 스레드의 가장 단순한 사례를 나타낸다. 이것은 그 어떠한 하드웨어 자원도 사용하지 않고, 그 어떠한 하드웨어 자 원을 기다리지도 않는다. 마찬가지로, HWR #1도 단순한 사례를 나타낸다. 어떠한 실행 스레드도 그것을 사용하지 않으며, 그 어떠한 실행 스레드도 그것을 사용하기 위해 기다리지 않는다. TOE #1 및 HWR #2은 조금 복잡한 사례를 나타낸다. TOE #1은 HWR #2를 사용하고 있지만, 그것을 사용하기 위해 기다리고 있는 다른 실행 스레드는 없다.

모든 것이 방금 기술한 대로 단순하게 거의 계속 유지되지는 않는다. 예를 들어, TOE #1이 HWR #2를 사용하고 있으며, TOE #2 또한 HWR #2를 사용할 필요가 있다면 어떻게 되겠는가? 통상적인 컴퓨터 시스템에서의 운영 체제는, 소프트웨어 잠금으로 하드웨어 자원으로의 액세스를 관리한다. 이하와 같은 대화가 있을 수 있다:

(1) TOE #1 : 나는 HWR #2를 사용해야 합니다.

(2) 운영 체제 : (잠금을 점검하고 업데이트한 후) 좋아, TOE #1. 그렇게 하세요.

(3) TOE #2 : 나도 HWR #2를 사용해야 합니다.

(4) 운영 체제 : (잠금을 점검한 후) 안 돼요, TOE #2. 기다리세요.

(5) TOE #1 : HWR #2를 다 썼습니다.

(6) 운영 체제 : (잠금을 업데이트한 후) 좋아, TOE #2. 사용하세요.

...

이 대화는 간단해서 모든 가능한 사례를 커버하지는 않는다. 예를 들면, TOE #1이 고장이 나거나 제대로 프로그래밍되지 않아, 단계 (4)가 절대 발생하지 않는다면 어떻게 되겠는가? 운영 체제는 이것 또한 처리해야 한다.

이제 도 1b를 참조해보면, 여기에는 최신 컴퓨터 시스템에서 점점 일반적인 것이 되어 가는 좀 더 복잡한 몇몇 시나리오들이 도시되어 있다. 예를 들면, 다수의 프로세서들 외에, 수행 중인 서로 다른 운영 체제들(예를 들면, 프로세서 #1의 윈도우즈(TM) 운영 체제 및 프로세서 #2의 리눅스 운영 체제)이 있을 수 있다. 또한, 도 1b에 나타나 있는 바와 같이, 그리고 곧 설명되는 바와 같이, 하드웨어 자원들은 그 자체가 또한 반드시 고려되어야만 하는 복잡한 특징들을 지닐 수 있다.

도 1b에서, 상술한 대화에 기초하는 것과 유사한 시나리오가 도시되어 있다. 여기서, TOE #2는 HWR #3을 사용하고 있고, TOE #3 또한 그것을 사용하기를 원한다. 예를 들면, 즉, HWR #3은 프린터이고, TOE #2이 텍스트 문자를 출력하기 위해 그것을 사용하고 있고, TOE #3은 이미지를 출력하기 위해 프린터를 사용하고자 한다.

다시 말하면, 통상적인 접근방법은 실행 스레드 각각을 제어하는 운영 체제가, 소프트웨어 잠금 방식으로 하드웨어 자원에 대한 이러한 분쟁을 관리하는 것이다. 통상적으로, 이러한 소프트웨어 잠금은 상호 배제 객체(종종, "mutex"라 지칭됨)로서 구현된다.

상호 배제 객체는, 다수의 실행 스레드들이, 파일 또는 프린터 액세스와 같은 동일한 하드웨어 자원을 단지 동시가 아니라 공유할 수 있게 하는 프로그램 객체이다. 실행 스레드가 시작되면, 공유된 하드웨어 자원 각각에 대해 고유하게 명명된 상호 배제 객체가 생성되고, 운영 체제(또는 시스템)에 의해 관리된다. 자원 을 필요로 하는 임의의 실행 스레드는 그것이 하드웨어 자원을 사용하는 동안은 상호 배제 객체를 잠궈서, 다른 실행 스레드로부터의 가능한 간섭을 막을 수 있다. 하드웨어 자원이 더 이상 필요가 없을 때 또는 하드웨어 자원을 이용하는 실행 스레드가 종료되었을 때 상호 배제 객체는 잠금 해제된다.

도 1b를 계속해보면, TOE #4는 여기서 심각한 문제가 일어날 수 있는 사례를 나타낸다. TOE #2와 TOE #3에 대해 지금 막 기술된 상황을 처리하기 위해 간단한 충돌 해결 메커니즘이 사용된다면, TOE #4는 HWR #3을 이용하는 자신의 차례를 얻기 위해 동작하지 않는 TOE #3 기다림을 끝낼 수 있다. 최신 대부분의 정교한 운영 체제들은, 비록 원하는 만큼 효율적이지 못할 수 있지만, 이러한 시나리오를 피하기 위한 메커니즘을 지니고 있다. 그러나, 모든 컴퓨터 시스템이 이러한 운영 체제를 사용하는 것은 아니며, 또한, 많은 애플리케이션에서, 이러한 정교한 운영 체제를 사용하여 그에 따르는 내재적인 부담을 질 이유가 없다. 따라서, 컴퓨터 시스템에서 하드웨어 자원을 액세스하기 위한 본래부터 부담이 적은 메커니즘을 사용하기 위한 요구 사항이 오늘날 여전히 존재한다. 즉, 특정 애플리케이션보다는 좀 더 정교하거나 또는 부담이 되는 운영 체제의 기능을 심하게 필요로 하지 않는 것이 실제로 필요할 수 있다.

또한, 예시한 것과 같이 어느 정도, 도 1b에서는 HWR #3과 HWR #4가 다중채널 하드웨어 장치(다중채널 HW)의 일부로서 도시되어 있다. 따라서, HWR #4가 프린터 집합 풀 중 HWR #3에 대해 모든 면이 동일한 또 다른 프린터인 경우, TOE #3으로부터의 가설 프린터 잡이 HWR #4로 그냥 다시 라우팅되면 좋을 것이다. 전통 적으로, 이러한 다중채널 하드웨어 자원을 관리하는 것은 운영 체제의 역할이었다.

도 2(배경 기술)를 또한 참조해보면, 여기에서는 전통적인 소프트웨어 잠금이 채용된 방식에서 TOE #2가 HWR #3의 사용을 어떻게 취득하는지를 나타내는 의사 코드의 목록이 있다. 우선, 프로세서 #2의 OS #2로 HWR #3의 소유권(즉, 도 2의 잠금 #2)이 확립된다. 이후, 프로세서 #1의 OS #1로 소유권(즉, 잠금 #1)이 확립된다. 이제 TOE #2는, 그 사용이 끝날 때까지 또는 운영 체제 중 하나가 간섭할 때까지 HWR #3을 사용할 수 있다. 이후 잠금 #1이 해제된다. 이후 잠금 #2가 해제된다. 다음에 설명되는 바와 같이, 도 2에 별표로 표시된 부분은 특히 관심을 가져야 하는 부분이다.

도 3a 내지 도 3d(배경 기술)는, 두 개의 대표적인 사례, 즉, 사용가능한(아이들 상태) 하드웨어 자원을 액세스하는 실행 스레드에 대한 최악의 사례 및 최선의 사례에 접근하는 가설 상황을 각각 도시하는 일련의 타이밍도이다. 도 3a 내지 도 3c는 전통적인 컴퓨터 시스템에서의 성능에서 하드웨어 자원의 빨라진 속도의 영향을 단계적으로 도시한다. 여기서 볼 수 있는 중요한 요점은, 하드웨어 자원 각각에 대한 듀티 사이클에 상관없이, 소프트웨어 잠금 관리에 대한 듀티 사이클이 본질적으로 계속 고정되게 유지된다는 것이다(물론, 하드웨어 자원이 아이들 상태가 아니면 이것은 증가될 수 있다). 따라서, 도 3c에 도시된 바와 같이, 최악의 사례는, 실행 스레드가 실제 작업을 하는 것이 아니라, 하드웨어 자원을 액세스하는 오버헤드를 처리하기 위해 자신의 프로세서 시간 대부분을 사용하는 경우이다.

이와는 대조적으로, 도 3d는 실행 스레드가 하드웨어 자원을 액세스하는 오버헤드에 자신의 프로세서 시간을 거의 쓰지 않는 최선의 경우를 나타내며, 따라서 실제적인 작업을 좀 더 할 수 있다. 도 3d에 도시된 경우는 명백하게 바람직하지만, 현재의 통상적인 방식하에서는 도달할 수 없는 것이다. 프로세서 기반 소프트웨어 잠금에 대해 사용되는 소프트웨어가 최적화될 수 있는 정도까지 본래 한계가 있으며, 최신 대부분의 운영 체제에서는 그 한계에 거의 도달했다.

예를 들면, 상호 배제 객체의 구현에 따라, 소정의 하드웨어 자원으로의 원자적(atomic) 액세스를 유지하기 위해 상호 배제 객체를 잠그고 잠금 해제하는, 그 "오버헤드"는 수 십 마이크로초 정도일 수 있다. 이것은 리눅스와 윈도우즈(TM)와 같이 보호되는 프로세스 메모리 공간을 사용하는 운영 체제의 경우 악화된다. 이것은 또한 상호 배제 객체가 멀티 프로세서로부터 안전해야 할 필요가 있는 경우 악화된다. 이들 일반적인 사례에서의 점점 증가하는 오버헤드의 크기는 상당히 더 클 수 있어, 하드웨어 가속기를 사용하는 성능 이점과 하드웨어 자원을 비동기가 되게 하는 이점 둘 모두를 부인하기 쉽다. 또한, 멀티 프로세서로부터 안전한 잠금은 주로 스핀 잠금으로 구현되며, 이것 모두는 다수의 프로세서 전체에 우선순위 반전을 가져올 수 있다.

따라서, 오늘날 컴퓨터 시스템의 하드웨어 자원들을 액세스하기 위한 더 효율적인 메커니즘에 대한 요구가 특히 여전히 존재한다.

따라서, 멀티 스레드된 컴퓨터 시스템에서 비동기 하드웨어 장치들을 효율적 으로 공유하기 위한 시스템을 제공하고자 한다.

간단하게, 본 발명의 하나의 바람직한 실시예는, 다수의 스레드를 갖는 적어도 하나의 소프트웨어 프로세스를 수행할 수 있는 컴퓨터 시스템의 하드웨어 자원을 공유하기 위한 시스템에 관한 것이다. 컴퓨터 시스템 내의 데이터 구조의 시스템은 lock_indicator를 포함한다. 제공된 로직은 요청 스레드라 정의된 스레드들 중 하나에 의해 하드웨어 자원을 사용하는 요청을 수신한다. 제공된 잠금 로직은, lock_indicator에 기초하여, 요청 스레드의 사용에 대해 하드웨어 자원이 사용가능한지 여부를 판정한다. 잠금 로직에 응하여, 제공된 로직은 하드웨어 자원이 사용가능하지 않다는 것을 대신 나타내는 lock_indicator를 설정하도록 제공된 로직을 제어하며, 요청에 대해 하드웨어 자원의 사용을 진행할 수 있다는 go_indicator로 신호하도록 제공된 로직을 제어한다. lock_indicator를 설정하는 로직은, 하드웨어 자원의 제어 하에서 특별히 동작한다.

이들 및 기타 구성요소들은, 본 발명을 수행하기에 현재 알려진 형태 중 최선의 형태의 설명과, 본 명세서에 설명되고 도면에 도시된 바람직한 실시예의 산업상 이용 가능성을 고려하여, 당업자들에게 명백할 것이다.

본 발명의 목적들 및 장점들은 첨부도면들과 연계하여 이하의 상세한 설명으로부터 명백해질 것이다.

상기 다양한 도면들에서는 동일하거나 유사한 요소들 또는 단계들을 나타내기 위하여 동일한 참조부호들이 이용된다.

<최선의 형태>

바람직한 일 실시예는 다중 스레드되고 잠재적으로는 멀티 프로세서 컴퓨터 시스템에서 비동기 하드웨어 자원의 공유를 위한 시스템이다. 본 명세서의 다양한 도면들에 도시된 바와 같이, 그리고 특히 도 4를 참조하면, 본 발명의 바람직한 실시예들이 일반적인 참조부호(10)에 의하여 설명된다.

간단히, 본 발명자들은 종래 기술의 접근들에서의 결점들이 운영 체제 또는 실제 하드웨어 자원들에 약하게 연결된(loosely tied) 이들을 이용하는 운영 체제들 때문이라는 것을 관찰하였다. 반대로, 이로 인해, 본 발명자들은 하드웨어 자원들의 보다 밀접한 제어, 따라서 보다 최적의 이용을 취득하기 위한 방법은 하드웨어 자원들이 그들의 이용을 제어하는 잠금 관리시 능동적으로 참여하도록 하는 것이라는 깨닫게 해주었다. 본 발명자들은 필요한 작업의 일부를 운영 체제나 운영 체제들에 의해 계속 처리하는 경우에도, 이 새로운 접근법을 "하드웨어 잠금"이라 지칭한다.

다시 도 1a-b 및 또한 이제 도 4의 개략적인 블록도를 간단히 참조하면, 본 발명의 하드웨어 잠금 시스템(10)이 최신 컴퓨터 시스템(12)과 연관되는 방법을 이해할 수 있다. 일반적으로, 그리고 특히 이하의 개시를 위하여, 컴퓨터 시스템(12)은 소프트웨어 애스펙트(SW aspect, 14) 및 하드웨어 애스펙트(HW aspect, 16)를 갖는 것으로 보일 수 있다. SW 애스펙트(14)는 운영 체제(OS, 18), 또는 다수의 운영 체제들이 이용된다면 운영 체제들을 포함하며, 실행 스레드(threads, 20)를 포함한다. 비록 일반적인 컴퓨팅의 관점에서는 부족하지만, 명백해 질 이유 들로 인해 여기에서는 모순되지 않으므로, 프로세서(CPU, 22), 또는 다수의 프로세서들이 이용되면 프로세서들이 SW 애스펙트(14)에 포함된다. 대조적으로, HW 애스펙트(16)는 SW 애스펙트(14)에 의하여 사용된 하드웨어 자원(24)을 포함하며, 선택적으로, 하나 이상의 유효 하드웨어 자원(24)을 포함하는 다중채널 하드웨어 장치들(26)을 포함할 수 있다.

도 5는 본 발명의 하드웨어 잠금 시스템(10)의 예시적인 실시예의 주요 데이터 구조(400)을 도시하는 개략적인 블록도이다. 이 데이터 구조(400)는 제어 비트들(412), 제어 레지스터들(414), 및 대기 목록들(416)을 포함한다.

각각의 하드웨어 자원(24)을 위하여 유지된 제어 비트들(412)은 Lock_bit(418), Go-bit(420), Ready_bit(422), PendWriter_bit(424), 및 PendReader_bit(426)를 포함한다. Lock_bit(418)는 하드웨어 자원(24)이 잠긴 것을 신호하는 기능을 한다. Go_bit(420)는 하드웨어 자원(24)의 이용이 개시되어야 하는 것을 신호하는 기능을 한다. Ready_bit(422)는 하드웨어 자원(24)이 그것에 요청된 것을 완료한 것을 신호하는 기능을 한다. PendWriter_bit(424) 및 PendReader_bit(426)는 각각 하드웨어 자원(24)에 대한 기입 또는 판독 동작들에 대한 보류중인 대기자들(pending waiters)이 존재하는 것을 신호하는 기능을 한다.

컴퓨터 시스템(12)이 다수의 프로세서들(CPUs, 22)을 가지면, 제어 비트들(412)은 각각의 CPU(22)에 대한 ProcEnable_bit(428)을 더 포함하며, 개별 하드웨어 자원들(24)을 위해서라기 보다는 일반적으로 유지된다.

제어 레지스터들(414)은 각각의 CPU(22)에 대한 ThreadID_reg(430)뿐만 아니 라, 제1 및 제2 임시 프로그램 카운터 레지스터들(PC_temp1_reg(432) 및 PC_temp2_reg(434)), 및 제1 및 제2 예외 주소 레지스터들(Ex_addr1_reg(436) 및 Ex_addr2_reg (438))을 포함한다. ThreadID_reg(430)는 현재 실행 스레드(20)의 고유 식별자를 저장하는데 사용된다. PC_temp1_reg(432) 및 PC_temp2_reg(434)는 프로그램 카운터의 현재 컨텐츠를 임시로 유지하는데 사용된다. 그리고 Ex_addr1_reg(436) 및 Ex_addr2_reg(438)는 기입 또는 판독 동작들에 대한 보류중인 대기자들의 부가(adding)를 처리하는 예외 루틴들(exception routines)에 대한 주소들을 유지하는데 사용된다. 동적으로 변하는 데이터 구조들(400) 내의 대부분의 요소들과는 달리, Ex_addr1_reg(436) 및 Ex_addr2_reg(438)는 개시시에 로드되어 변하지 않을 수 있다.

컴퓨터 시스템(12)이 다중채널 하드웨어 장치들(26)을 갖는 경우, 제어 레지스터들(414)은 각각의 채널(유효 하드웨어 자원(24))에 대하여 ReqID_reg(440)를 더 포함한다.

각각의 하드웨어 자원(24)에 대하여 유지된 대기 목록들(416)은 WriteWaiters_lst(444) 및 ReadWaiters_lst(446)를 포함한다. 이들은 주어진 시간에 하드웨어 자원(24)을 이용하는 것을 대기중인 스레드들(20)(만약 존재한다면)의 목록들을 각각 유지한다.

도 6a-g는 하드웨어 가속기를 프로그램하는데 본 발명의 하드웨어 잠금 시스템(10)을 이용하는 처리예(500)를 도시하는 일련의 흐름도이다. 도 6a는 전체 흐름도를 도시하며, 도 6b-d는 HW 애스펙트(16)에 의하여 수행되는 도 6a의 "원자적" 단계들의 세부사항들을 도시하고, 도 6e-g는 SW 애스펙트(14)에 의하여 수행되는 도 6a의 단계들의 세부사항들을 도시한다.

집합적으로 이 가정적인 하드웨어 가속기 예의 환경에서, 도 6a-g는 특히 고려할 만한 다섯 개의 경우들을 도시한다.

경우 1: 하드웨어 자원(24)이 이용 가능할 때 잠금(lock)을 취득;

경우 2: 하드웨어 자원(24)이 다른 스레드(20)에 의하여 "소유"될 때 잠금을 취득;

경우 3: 요청 완료후 하드웨어 자원(24)의 요청의 완료에 대한 정보 취득;

경우 4: 요청 완료전 하드웨어 자원(24)의 요청의 완료에 대한 정보 취득; 및

경우 5: 하드웨어 자원(24)에 의한 요청 완료에 대하여 대기자들에게 통지.

<경우 1:>

도 6a에서 프로세스(500)의 단계(502) 내지 단계(512)는 경우 1을 포함한다. 단계(502)에서 프로세스(500)에 들어가며, 단계(504)에서 하드웨어 자원(24)의 이용을 찾는 스레드(20)로부터의 요청이 수신된다.

단계(506)에서 하드웨어 자원(24)이 이용 가능한지 여부(즉, Lock_bit(418)가 현재 "0"으로 설정되어 있다면)에 대한 결정이 이루어진다. 여기에서, 하드웨어 자원(24)은 이용 가능하다(대안은 경우 2임, 다음에 기술함). 따라서, 단계(508)에서 본 발명의 스레드(20)는 Lock_bit(418)에 "1"을 기입한다. 다중채널 하드웨어 장치(26)가 존재할 때 하드웨어 잠금 시스템(10)은 모든 채널들(하드웨어 자원들(24))이 사용될 때까지 일련의 Lock_bits(418)(또는 등가의 메커니즘)로의 "1"의 기입을 가능하게 할 수 있다는 점을 주목한다.

본 발명의 스레드(20)는 이제 하드웨어 자원(24)의 "소유권"을 가지며, 단계(510)에서 하드웨어 자원(24)에 요청하고 있는 어떤 것에 대하여도 이용될 범용 레지스터들, 등을 프로그램하는 것을 진행한다. 이 후, 단계(512)에서, 스레드(20)는 Go_bit(420)을 설정하여 하드웨어 자원(24)의 사용이 즉시 개시될 수 있음(여기서, Go_bit(420)는 단순히 트리거이며, 다른 비트들과 같이 "1" 및 "0" 토글로서 이용되지 않음)을 신호한다.

스레드(20)는 이제 하드웨어 자원(24)을 취득하였으며 경우 1은 종료된다.

<경우 2:>

도 6a에서 단계(502) 내지 단계(506) 및 단계(514) 내지 단계(516)는 경우 2를 포함한다. 하드웨어 자원(24)이 이용 가능하지 않다는 것(즉, 여기서 Lock_bit(418)은 현재 "1"로 설정)을 제외하고는 단계들(502-506)은 전술된 바와 동일하게 진행한다. 따라서, 단계(514)에서 HW 애스펙트(16)는 기입 대기자들의 목록(WriteWaiters_lst(444))에 대기자를 추가할 준비를 한다. HW 애스펙트(16)는 컴퓨터 시스템(12)의 SW 애스펙트(14)에 대하여 "원자적으로" 단계(514)를 처리하므로, 전통적인 소프트웨어 잠금 방식들에서 필요한 번거럽고 에러가 발생하기 쉬운 루틴들을 회피한다. 이 후, 단계(516)에서 SW 애스펙트(14)는 하드웨어 자원(24)이 다시 이용 가능하게 되는 것을 "대기"한다. 그 후, 처리(500)는 단계(504)로 복귀하며, 여기에서는 특정한 하드웨어 자원(24)을 잠그려는 다른 시도 가 개시될 수 있다.

도 6b는 단계(514)를 상세히 도시한다. 단계(518)에서 HW 애스펙트(16)는 PC_temp1_reg(432)에 프로그램 카운터를 저장한다. 단계(520)에서 HW 애스펙트(16)는 PendWriter_bit(424)를 "1"로 설정한다. 단계(522)에서 HW 애스펙트(16)는 인터럽트들을 디세이블하여, 문맥 전환(context switching)의 기회를 방지하고 일관성을 유지한다. 컴퓨터 시스템(12)이 다수의 프로세서들(CPUs, 22)을 갖는다면, 단계(524)에서 HW 애스펙트(16)는 ProcEnable_bits(428)의 각각이 디세이블하도록 설정함으로써 다른 프로세서들이 동작하지 않게 하여, WriteWaiters_lst(444) 내의 엔트리들이 일관성을 유지하는 것을 확실히 한다. 그리고 단계(526)에서 HW 애스펙트(16)는 프로그램 카운터를 jumpToAddWriteWaiters 내의 주소로(즉, Ex_addr1_reg(436)에 저장되어 있는 것으로) 설정한다.

HW 애스펙트(16)가 조금 전에 기술된 필수 준비 작업을 "원자적으로" 처리하였기 때문에, SW 애스펙트(14)는 안전하게 단계(516)로 진행할 자유를 갖는다.

도 6e는 본 발명의 실시예에 따른 하드웨어 잠금 시스템(10)에 대하여 상세하게 단계(516)를 도시한다. 여기에서 스레드(20)와 연관된 세마포어들(semaphores)은 대기 메커니즘으로서 이용되며 SW 애스펙트(14)는 대기 스레드의 우선 순위 목록을 유지한다. [물론, FIFO 또는 다른 순서 배열이 대안의 실시예들에서 이용될 수 있다.]

단계(528)에서 SW 애스펙트(14)는 ThreadID_reg(430) 및 현재 스레드(20)에 대한 그 우선 순위를 취득한다. 단계(530)에서 SW 애스펙트(14)는 어느 WriteWait 세마포어가 이 특정 스레드(20)과 연관되는지를 알아낸다. 단계(532)에서 SW 애스펙트(14)는 본 예에서의 스레드 우선 순위에 기초하여, 이 WriteWait 세마포어를 WriteWaiters_lst(444)로 삽입한다. 단계(533)에서 SW 애스펙트(14)는 PC_temp1_reg(432)의 사본을 저장한다(그 이유는 후술됨). 단계(534)에서 SW 애스펙트(14)는 인터럽트들을 인에이블하고, 다수의 프로세서들(CPUs, 22)이 존재하면, 다른 프로세서들을 정지 해제한다(그들의 각각의 ProcEnable_bits(428)가 그들을 인에이블하도록 설정함). 단계(536)에서 SW 애스펙트(14)는 WriteWait 세마포어상에 보류중인 본 발명의 스레드(20)를 남겨둔다[이 대기는 잠재적으로 무한하지만, 통상적으로 Lock_bit(418)가 해제되며 이 스레드(20)는 WriteWaiters_lst(444)의 최상위에 도달하며, 세마포어는 신호된다(부가적인 설명은 이하에 제공됨).] 단계(538)에서 SW 애스펙트(14)는 WriteWait 세마포어가 취해진 것을 관찰한다. 그리고 단계(540)에서 SW 애스펙트(14)는 PC_tmep1_reg(432)의 이전에 저장된 컨텐츠로 프로그램 카운터를 로드한다(인터럽트들이 다시 인에이블되기 직전에 저장된 사본은 올바른 것으로 알려진다).

<경우 3 내지 4에 대한 프리퀄>

Go_bit(420)이 설정되어, 하드웨어 자원(24)의 이용이 즉시 시작할 수 있음을 신호하는 것으로 경우 1(잠금 취득)이 종료된 것을 생각하자. 그 후, SW 애스펙트(14)는 요청에 관련되지 않은 기타 작업을 계속 수행할 수 있지만, 결국에는 요청이 완료되었는지를 알기 위해 검사할 것이다. SW 애스펙트(14)는 Ready_bit(422)를 판독함으로써 이를 행한다. 다중채널 하드웨어 장치(26)가 존재 하는 경우, 하드웨어 잠금 시스템(10)은 (하드웨어 자원(24)인) 채널에 대한 ThreadID_regs(430)의 각 콘텐츠에 기초하여 이러한 요청을 구별해야 한다.

다시 도 6a를 참조하면, (Go_bit(420)가 이를 신호하는) 단계(512) 다음에, 단계(542)에서, HW 애스펙트(16)는 본원에서 이용되는 예시적인 하드웨어 가속기 동작을 수행한다. 그 다음에, 단계(544)에서, HW 애스펙트(16)는 Ready_bit(422)를 설정하여, 하드웨어 자원(24)이 요청된 것을 완료했음을 신호한다. 그 다음에, 단계(546)에서, HW 애스펙트(16)는 Lock_bit(418)를 리셋함으로써, 하드웨어 자원(24)이 다시 이용 가능함을 신호한다.

또한, 단계(548)에서, SW 애스펙트(14)는 원하는 구성 요소 특정 동작이 무엇이든 수행할 수 있다(예를 들어, 하드웨어 자원(24)에 관련되지 않은 작업, 병렬 실행, 또는 단순히 아무것도 아님).

<경우 3:>

도 6a에서, 단계(550) 및 단계(552)는 (요청 완료 후에 정보를 얻는) 경우 3을 포함한다. 단계(550)에서, SW 애스펙트(14)는 Ready_bit(422)가 설정되는지를 결정한다. 여기서, 하드웨어 자원(24)은 완료되었고, Ready_bit(422)는 리셋되었다(대안으로는 아래에 설명되는 경우 4가 있음). 따라서, 단계(552)가 뒤어어 오고, 프로세스(500)에서 나간다.

<경우 4:>

도 6a에서, 단계(550), 단계(554), 단계(556), 및 단계(552)는 (요청 완료 전에 정보를 취득하는) 경우 4를 포함한다. 단계(550)에서, SW 애스펙트(14)는 Ready_bit(422)가 설정되는지를 결정한다. 단지 이 단계에서만, 하드웨어 자원(24)이 아직 완료되지 않았고, Ready_bit(422)가 아직 리셋되지 않았다. 따라서, 단계(554)가 뒤이어 오고, 이 단계에서 HW 애스펙트(16)는 판독 대기자의 목록(ReadWaiter_lst(446))에 대기자 추가를 준비한다. 또한, HW 애스펙트(16)는 컴퓨터 시스템(12)의 SW 애스펙트(14)와 관련하여 "원자적으로(atomically)"으로 단계(554)를 처리함으로써, 통상의 소프트웨어 잠금 방식에서 필요로 하는 번거롭고 틀리기 쉬운 루틴을 회피할 수도 있다. 그 다음에, 단계(556)에서, SW 애스펙트(14)는 하드웨어 자원(24)이 요청된 것을 완료하기를 "대기"한다. 그 다음에, 단계(552)가 뒤이어 오고, 프로세스(500)에서 나간다.

도 6c는 단계(554)를 상세히 도시한다. 단계(558)에서, HW 애스펙트(16)는 PC_temp2_reg(434)에 프로그램 카운터를 기억한다. 단계(560)에서, HW 애스펙트(16)는 PendReader_bit(426)를 "1"로 설정한다. 단계(562)에서, HW 애스펙트(16)는 인터럽트를 디세이블한다(문맥 전환(context switching)을 방지 및 일관성 유지). 컴퓨터 시스템(12)이 다수의 CPU(22)를 갖는 경우에는, 단계(564)에서, HW 애스펙트(16)가 각각의 ProcEnable_bits(428)의 설정에 의해 다른 것을 실속(stall)시켜 디세이블함으로써, ReadWaiters_lst(446) 내의 엔트리가 일관성을 유지하도록 한다. 또한, 단계(566)에서, HW 애스펙트(16)는 프로그램 카운터를 jumpToAddReadWaiters 내의 주소(즉, Ex_addr2_reg(438)에 기억되어 있는 주소)로 설정한다.

SW 애스펙트(14)는 (요청의 완료를 대기하고 있는 스레드(20)의 목록인) ReadWaiters_lst(446)에 스레드(20)를 추가해야 한다. 이는, 다중채널 하드웨어 장치(26)를 채용하는 경우에만 요구된다. 단일 채널 하드웨어 자원(24)만이 존재하는 경우에는, 하나의 대기 중인 스레드(20)만이 존재할 수 있고, ReadWaiters_lst(446)은 단일 요소만을 가질 것이다.

HW 애스펙트(16)가 방금 설명한 필수 준비 작업을 "원자적으로" 처리하였기 때문에, SW 애스펙트(14)는 단계(556)에서 안전하게 자유로이 진행될 수 있다.

도 6f는 본 발명의 실시예에 따른 하드웨어 잠금 시스템(10)의 단계(556)를 상세히 도시한다. 여기서, 스레드(20)와 연관된 세마포어도 또한 대기 메커니즘으로서 이용되고, SW 애스펙트(14)는 대기 중인 스레드의 우선 순위 정렬된 목록을 유지한다[FIFO 또는 다른 순서 배열을 선택적으로 이용할 수 있다.]

단계(568)에서, SW 애스펙트(14)는 ThreadID_reg(430) 및 현재 스레드(20)에 대한 우선 순위를 취득한다. 단계(570)에서, SW 애스펙트(14)는 이 특정 스레드(20)와 어느 ReadWait 세마포어가 연관되는지를 찾는다. 단계(572)에서, SW 애스펙트(14)는 본 예의 스레드 우선 순위에 기초하여, ReadWaiters_lst(446)에 이 ReadWait 세마포어를 삽입한다. 단계(573)에서, SW 애스펙트(14)는 (아래에 설명하는 이유 때문에) PC_temp2_reg(434)의 사본을 저장한다. 단계(574)에서, SW 애스펙트(14)는 인터럽트를 이네이블하고, 다수의 CPU(22)가 존재하는 경우에는, 다른 것을 정지 해제한다(그 각각의 ProcEnable_bits(428)를 설정하여 이네이블함). 단계(576)에서, SW 애스펙트(14)는 현재 스레드(20)를 (무한일 수 있는) ReadWait 세마포어에 보류시킨다. 단계(578)에서, SW 애스펙트(14)는 ReadWait 세마포어를 취득했는지를 관찰한다. 또한, 단계(580)에서, SW 애스펙트(14)는 PC_temp2_reg(434)로서 이전에 저장된 것 다음의 명령어 주소로 프로그램 카운터를 로드한다(인터럽트를 다시 이네이블하기 바로 전에 저장된 사본이 맞는 것으로 알려지면, 다음 원하는 명령에 대한 오프셋이 필요하다).

<경우 5에 대한 프리퀄:>

(단계(546)에서) 본 예시적인 하드웨어 가속기가 완료된 후에, HW 애스펙트(16)가 Lock_bit(418)를 리셋함을 생각하자. 그 다음에, HW 애스펙트(16)는 하드웨어 자원(24)이 이용 가능하게 될 때까지 대기하는 스레드(20)가 존재하는지(예를 들어, 경우 2 참조) 또는 하드웨어 자원(24)이 요청 처리를 완료할 때까지 대기하는 스레드(20)가 존재하는지(예를 들어, 경우 4 참조)를 검사한다. HW 애스펙트(16)는 단계(582)에서 PendWriter_bit(424)를 검사하고, 단계(584)에서 PendReader_bit(426)를 검사함으로써 이를 행한다. 이들 중 어느 것도 설정되지 않은 경우에는, 어떤 대기자도 통지되지 않고, 단계(552)가 뒤이어 오고, 프로세스(500)에서 나간다.

<경우 5:>

도 6a에서, 단계(586), 단계(588), 및 단계(552)는 (요청 완료에 대한 대기자를 통지하는) 경우 5를 포함한다. 단계(586)에서, HW 애스펙트(16)는 인터럽트를 생성하고, 인터럽트 서비스 루틴(interrupt service routine; ISR) 실행을 시작한다. 단계(514)와 단계(554)에서와 같이, 단계(586)은 SW 애스펙트(14)에 대해 "원자적으로" 행해지고, HW 애스펙트(16)가 그 처리를 용이하게 하도록 한다. 그 다음에, 단계(588)에서, SW 애스펙트(14)는 ISR을 완료한다. 다음 단계(552)가 뒤이어 오고, 프로세스(500)에서 나간다.

도 6d는 단계(586)를 상세히 도시한다. 다중채널 하드웨어 장치(26)를 채용하는 경우, 단계(590)에서, HW 애스펙트(16)는 완료된 요청의 ID인 ReqID_regs(440)를 갱신한다. 단계(592)에서, HW 애스펙트(16)는 PendWriter_bit(424)를 리셋하고, 단계(594)에서, HW 애스펙트(16)는 PendReader_bit(426)를 리셋한다. 다수의 CPU(22)가 존재하는 경우, 단계(596)에서, HW 애스펙트(16)는 다른 것을 각각의 ProcEnable_bits(428)의 설정에 의해 디세이블하여 동작하지 않도록 한다. 또한, 단계(598)에서, HW 애스펙트(16)는 연관된 ISR에 의해 서비스되는 인터럽트를 생성한다.

HW 애스펙트(16)가 방금 설명한 필수 준비 작업을 "원자적으로" 처리하였기 때문에, SW 애스펙트(14)는 단계(588)로 안전하게 자유로이 진행할 수 있다.

도 6g는 본 발명의 실시예에 따른 하드웨어 잠금 시스템(10)의 단계(588)를 상세히 도시한다. 단계(600)에서, SW 애스펙트(14)는 하드웨어 자원(24)의 프로그래밍을 대기 중인 스레드(20)의 목록이 하나 이상의 엔트리를 갖는지를 결정한다. 하나 이상의 엔트리를 갖는 경우, 단계(602)에서, PendWriter_bit(424)를 "1"로 설정한다. 또한, 단계(604)에서, SW 애스펙트(14)는 하드웨어 자원(24)의 최종 요청의 완료를 대기 중인 스레드(20)의 목록이 하나 이상의 엔트리를 갖는지를 결정한다. 하나 이상의 엔트리를 갖는 경우, 단계(606)에서, PendReader_bit(426)를 "1"로 설정한다. 다음으로, 단계(608)에서, SW 애스펙트(14)는 하드웨어 자원(24)의 프로그래밍을 대기 중인 스레드(20)의 목록으로부터, 최상위 엔트리가 있는 경우 이를 가져온다(WriteWaiters_lst(444)). 이와 유사하게, 단계(610)에서, SW 애스펙트(14)는 하드웨어 자원(24)의 완료된 요청과 연관된 스레드(20)의 목록으로부터, 최상위 엔트리가 있는 경우 이를 가져온다(ReadWaiters_lst(446)). 이러한 상황은 다중채널 하드웨어 장치(26)가 존재하는 경우 가능하다. 이러한 이유로, HW 애스펙트(16)는, SW 애스펙트(14)에 의해 나중에 판독될 수 있는 프로그래밍 시 (ReqID_regs(440)에서) 고유 ID를 할당하여 이네이블함으로써 스레드(20)를 각각의 ReqID_regs(440)와 연관시킬 수 있어야 한다.

다음으로, 단계(612)에서, SW 애스펙트(14)는 (프로그래밍을 대기 중인 스레드와 완료를 대기 중인 스레드 모두인) 스레드(20)를 연관된 세마포어를 통해 신호한다.

다수의 CPU(22)가 존재하는 경우, 다음으로, 단계(614)에서, SW 애스펙트(14)는 단계(596)에서 정지된 스레드를 정지 해제한다(이는 ISR과 다른 프로세서가 이러한 동작 동안 정지되었고, 목록의 수정이 안전하고 일관된 상태를 유지할 것이기 때문이다). 또한, 단계(616)에서, SW 애스펙트(14)는 인터럽트로부터 복귀한다.

요약하면, 본 발명의 하드웨어 잠금 시스템(10)은 특히 문맥 전환 및 잠금을 취득하고 해제하는 오버헤드를 최소화한다는 관점에서, 더 일반적인 순수 소프트웨어 기반 잠금 구현에 비해 상당한 실행 시간 성능 개선을 제공함을 명확하게 알 수 있다. 일반적으로, 하드웨어 잠금 시스템(10)은 종래 접근법보다 최신 컴퓨터 시 스템 내의 하드웨어에 액세스하기 위한 덜 번거로운 고유 메커니즘을 제공하고, 또한 종래 접근법보다 이러한 하드웨어 자원에 접근하기 위한 더 효율적인 메커니즘을 특히 제공한다.

하드웨어 잠금 시스템(10)을 이용하는 경우, 사용 중이 아닌 하드웨어 자원(24)을 프로그래밍하는 오버헤드가 없다(즉, 소프트웨어 잠금의 상당한 오버헤드를 초래할 필요가 없다). 하드웨어 자원(24) 자체가 (동일 및 서로 다른 CPU(22) 모두에서 실행되는) 스레드(20) 내의 액세스 독점을 보장한다.

이와 유사하게, 하드웨어 잠금 시스템(10)은 하드웨어 자원(24)이 이미 요청을 완료한 경우 완료 정보를 얻을 때 어떤 오버헤드도 갖지 않는다. 예를 들어, 여기서, 스레드(20)가 대기자 목록(ReadWaiters_lst(446))에 삽입되어 요청 완료에 대해 통지받은 후, 하드웨어 자원(24)은 인터럽트를 생성할 것이고, 연관된 ISR은 완료에 대한 대기자 목록 내의 상위 요소를 신호할 것이다. 그 다음에, ISR은 스레드(20)가 완료에 대해 통지받도록 요청하였는지에 관계없이 실행될 것이다. 따라서, 여기서 ISR은 대기 중인 스레드(20)가 존재하는 경우에만 실행된다.

또한, 하드웨어 잠금 시스템(10)은 하드웨어 자원(24)을 프로그래밍하기 위해 대기 중인 대기자에 대한 목록(예를 들어, WriteWaiters_lst(444) 및 ReadWaiters_lst(446))을 자유로이 정렬할 수 있다. 임의의 원하는 정렬도 가능하므로, 구현자(implementer) 마음대로 정렬할 수 있다. 이와는 달리, 종래 소프트웨어 잠금에 따르면, 잠금을 위한 대기자는 FIFO, LIFO, 또는 OS에 의해 정렬된 우선 순위 중 하나이다.

대체로, 본 문헌은 적어도 다수의 스레드를 갖는 하나의 소프트웨어 프로세스를 실행하는 컴퓨터 시스템 내의 하드웨어 자원을 공유하기 위한 적어도 방법 및 시스템을 개시한다. lock_indicator는 컴퓨터 시스템 내의 데이터 구조에 제공된다. 요청 스레드인 것으로 정해지는 스레드 중 한 스레드에 의한 하드웨어 자원 이용 요청을 수신한다. lock_indicator에 기초하여, 요청 스레드에 의한 이용을 위해 하드웨어 자원이 이용 가능한지를 결정한다. lock_indicator가 하드웨어 자원이 이용 가능한 것으로 지시하면, lock_indicator는 하드웨어 자원이 이용 가능하지 않음을 지시하는 대신 하드웨어 자원의 제어 하에 설정되고, go_indicator는 요청에 대한 하드웨어 자원의 이용이 현재 진행될 수 있음을 지시하도록 신호한다.

이상, 여러 실시예들을 설명하였지만, 이들은 단지 일 예로서 제시되었고, 본 발명의 폭과 범위는 상술한 예시적인 실시예들 중 어느 실시예에도 한정되지 않으며 그 대신 단지 다음 청구항과 그 등가물에 따라 정해진다는 것을 이해해야 한다.

Claims

다수의 스레드들을 갖는 적어도 하나의 소프트웨어 프로세스를 가동시키는 컴퓨터 시스템 내에서 하드웨어 자원을 공유하는 방법으로서,

(a) 상기 컴퓨터 시스템 내의 데이터 구조 내에 lock_indicator를 제공하는 단계와,

(b) 요청 스레드로 되도록 정의된 스레드들 중 하나에 의해 상기 하드웨어 자원을 이용하기 위한 요청을 수신하는 단계와,

(c) 상기 lock_indicator에 기초하여, 상기 요청 스레드에 의해 상기 하드웨어 자원이 이용가능한지 여부를 판정하는 단계와,

(d) 상기 (c) 단계에서, 상기 하드웨어 자원이 이용가능한 것으로 나타난 경우, (1) 상기 하드웨어 자원의 제어하에 상기 lock_indicator를 설정시켜서, 상기 하드웨어 자원이 이용가능하지 않음을 대신 나타내며, (2) 상기 요청에 대한 상기 하드웨어 자원의 이용이 진행될 수 있음을 나타내기 위해 go_indicator로 신호하는 단계

를 포함하는 하드웨어 자원 공유 방법.
제1항에 있어서,

상기 (a) 단계는, 상기 데이터 구조 내에 적어도 하나의 thread-identity_value를 저장할 수 있는 write-waiter_list를 더 제공하는 단계를 포함하 며,

(e) 상기 (c) 단계에서 상기 하드웨어 자원이 이용가능하지 않은 것으로 나타난 경우, (1) 상기 요청 스레드를 식별하는 상기 thread-identity_value를 상기 write-waiter_list에 추가하고, (2) 상기 하드웨어 자원의 이용이 가능해질 때까지 상기 요청 스레드를 대기시키는 단계를 더 포함하는 하드웨어 자원 공유 방법.
제2항에 있어서,

상기 (e) 단계의 (1)은, 상기 하드웨어 자원의 제어 하에서 스레드들에 따라 원자적으로 수행되는 하드웨어 자원 공유 방법.
제1항에 있어서,

상기 (a) 단계는, 상기 데이터 구조 내에 ready_indicator를 제공하는 단계를 더 포함하며,

(e) 상기 요청의 완료시에, (1) 상기 하드웨어 자원의 제어 하에 상기 ready_indicator를 설정시켜, 상기 요청이 완료되었음을 상기 요청 스레드에 신호하고, (2) 상기 하드웨어 자원의 제어 하에 상기 lock_indicator를 리셋시켜, 상기 하드웨어 자원이 다시 이용가능함을 나타내는 단계를 더 포함하는 하드웨어 자원 공유 방법.
제4항에 있어서,

상기 (a) 단계는, 상기 데이터 구조 내에 적어도 하나의 thread-identity_value를 저장할 수 있는 read-waiter_list를 제공하는 단계를 더 포함하며,

(f) 상기 ready_indicator에 기초하여 상기 하드웨어 자원이 상기 요청을 완료하였는지의 여부를 판단하는 단계와,

(g) 상기 (f) 단계에서 상기 하드웨어 자원이 상기 요청을 완료하지 않은 것으로 나타난 경우, (1) 상기 요청 스레드를 식별하는 상기 thread-identity_value를 상기 read-waiter_list에 추가하고, (2) 상기 요청이 완료될 때까지 상기 요청 스레드를 대기시키는 단계를 더 포함하는 하드웨어 자원 공유 방법.
제5항에 있어서,

상기 (g) 단계의 (1)은 상기 하드웨어 자원의 제어 하에서 스레드들에 따라 원자적으로 수행되는 하드웨어 자원 공유 방법.
제4항에 있어서,

(f) 상기 (e) 단계 후에, 상기 하드웨어 자원에 대해 기록 또는 판독하기 위해 기다리고 있는 임의의 스레드가 있는지 여부를 판단하고, 임의의 스레드가 있는 경우, (1) 상기 하드웨어 자원의 제어 하에 상기 컴퓨터 시스템 내에 인터럽트를 발생시키고, (2) 상기 인터럽트 기간 동안, 상기 하드웨어 자원에 대해 기록 또는 판독하기 위해 기다리고 있는 적어도 하나의 스레드에게 진행되어야 함을 신호하는 단계를 더 포함하는 하드웨어 자원 공유 방법.
제7항에 있어서,

상기 (e) 단계 및 상기 (f) 단계는 상기 하드웨어 자원의 제어 하에 스레드들에 따라 원자적으로 수행되는 하드웨어 자원 공유 방법.
제7항에 있어서,

상기 (f) 단계의 (1)은 상기 하드웨어 자원의 제어 하에 스레드들에 따라 원자적으로 수행되는 하드웨어 자원 공유 방법.
다수의 스레드들을 갖는 적어도 하나의 소프트웨어 프로세스를 가동시키는 컴퓨터 시스템 내에서 하드웨어 자원을 공유하기 위한 시스템으로서,

상기 컴퓨터 시스템 내에서 lock_indicator를 포함하는 데이터 구조;

요청 스레드로 되도록 정의되는 스레드들 중 하나에 의해 상기 하드웨어 자원을 이용하기 위한 요청을 수신하는 수단;

상기 lock_indicator에 기초하여 상기 요청 스레드에 의해 상기 하드웨어 자원이 이용가능한지 여부를 판정하는 잠금 수단; 및

상기 잠금 수단에 응답하여, 상기 하드웨어 자원의 제어하에 상기 lock_indicator를 설정시켜 상기 하드웨어 자원이 이용가능하지 않음을 대신 나타내기 위한 수단과, 상기 요청에 대한 상기 하드웨어 자원의 이용이 진행될 수 있음 을 나타내기 위해 go_indicator로 신호하는 수단을 제어하는 수단

을 포함하는 하드웨어 자원 공유 시스템.
제10항에 있어서,

상기 데이터 구조는 적어도 하나의 thread-identity_value를 저장하기 위한 writer-waiter_list를 더 포함하며,

상기 잠금 수단에 응답하는 수단은 또한, 상기 하드웨어 자원의 제어 하에, 스레드들에 따라 원자적으로 동작하는 상기 write-waiter_list에, 상기 요청 스레드를 식별하는 상기 thread-identity_value를 추가하는 수단과, 상기 하드웨어 자원의 이용이 가능해질 때까지 상기 요청 스레드를 대기시키는 수단을 제어하는 하드웨어 자원 공유 시스템.
제10항에 있어서,

상기 데이터 구조는 ready_indicator를 더 포함하고,

상기 요청의 완료에 응답하여, 상기 하드웨어 자원의 제어 하에 상기 ready_indicator를 설정시켜 상기 요청이 완료되었음을 상기 요청 스레드에 신호하는 수단과, 상기 하드웨어 자원의 제어 하에 상기 lock_indicator를 리셋시켜 상기 하드웨어 자원이 다시 이용가능함을 나타내는 수단을 제어하는 수단을 더 포함하는 하드웨어 자원 공유 시스템.
제12항에 있어서,

상기 데이터 구조는 적어도 하나의 thread-identity_value를 저장하기 위한 read-waiter_list를 더 포함하며,

상기 ready_indicator에 기초하여 상기 하드웨어 자원이 상기 요청을 완료하였는지의 여부를 판단하는 준비(ready) 수단과,

상기 준비 수단에 응답하여, 상기 하드웨어 자원의 제어 하에, 상기 요청 스레드를 식별하는 상기 thread-identity_value를, 스레드들에 따라 원자적으로 동작시키는 상기 read-waiter_list에 추가하는 수단과, 상기 요청이 완료될 때까지 상기 요청 스레드를 대기시키는 수단을 제어하는 수단을 더 포함하는 하드웨어 자원 공유 시스템.
제12항에 있어서,

상기 하드웨어 자원에 대해 기록 또는 판독하기 위해 기다리고 있는 임의의 스레드가 있는지 여부를 판단하기 위한 대기(waiter) 수단과,

상기 대기 수단에 응답하여, 상기 하드웨어 자원의 제어 하에 스레드들에 따라 원자적으로 동작하는 인터럽트를, 상기 하드웨어 자원의 제어 하에 상기 컴퓨터 시스템 내에 발생시키는 수단과, 상기 인터럽트 기간 동안, 상기 하드웨어 자원에 대해 기록 또는 판독하기 위해 기다리고 있는 적어도 하나의 스레드가 진행되어야 함을 신호하는 수단을 제어하는 수단을 더 포함하는 하드웨어 자원 공유 시스템.
제14항에 있어서,

상기 요청의 완료에 응답하여 제어하는 수단, 상기 ready_indicator를 설정시키는 수단, 상기 lock_indicator를 리셋시키는 수단, 및 상기 대기 수단은 상기 하드웨어 자원의 제어 하에 스레드들에 따라 원자적으로 동작하는 하드웨어 자원 공유 시스템.