KR20120106890A

KR20120106890A - 멀티코어 아키텍처 내의 리소스 관리

Info

Publication number: KR20120106890A
Application number: KR1020127020977A
Authority: KR
Inventors: 마크 데이비드 립페티
Original assignee: 후지쯔 세미컨덕터 가부시키가이샤; 시놉시스, 인크.
Priority date: 2004-03-31
Filing date: 2005-03-30
Publication date: 2012-09-26
Anticipated expiration: 2025-03-30
Also published as: EP1730628A1; JP2013211050A; CN100517219C; KR20120003014A; TWI502511B; JP6018021B2; EP1730628B1; CN1993674A; KR101248170B1; JP2013061947A; TW201337768A; GB0407384D0; TW200602981A; KR101258502B1; JP2007531137A; KR101239082B1; TW201337769A; TWI541725B; WO2005096143A1; TWI407373B

Abstract

프로세싱 실행가능한 트랜잭션에 대해 리소스를 제공하는 다수의 인터커넥트(interconnect)된 프로세서 요소를 구비하는 멀티코어 프로세서에 설치하기 위한 리소스 관리 및 태스크 할당 제어기로서, 상기 요소들 중 적어도 하나는 마스터 프로세싱 유닛이고; 상기 제어기는 설치될 때 마스터 프로세싱 유닛을 포함하는 각각의 프로세서 요소와 통신하도록 구성되며, 미리 정의된 할당 파라미터에 따라서 멀티코어 프로세서 내의 실행가능한 트랜잭션들을 특정 프로세서 요소들에 할당하는 제어 로직을 포함하는 리소스 관리 및 태스크 할당 제어기.

Description

멀티코어 아키텍처 내의 리소스 관리{RESOURCE MANAGEMENT IN A MULTICORE ARCHITECTURE}

본 발명은 멀티코어 아키텍처 내의 리소스 관리 방법 및 장치에 관한 것이다.

요즈음, 복잡한 이종 멀티코어 아키텍처를 통합하고 있는 반도체 디바이스가 유비쿼터스 데스크톱 컴퓨터에서부터, 휴대폰, PDA, 및 고속 텔레콤 또는 네트워크 스위칭 장비와 같은 최근의 현대식 전자 디바이스에까지 매우 다양한 시스템 및 장치에 사용되고 있다.

임의의 컴퓨터 프로세서의 의도하는 사용이 무엇이든 간에, 프로세서 제조자는 현재의 프로세서의 성능을 증가시키는 한편 이들의 단위 "비용"을 유지하거나 절감시키기 위해 계속해서 노력하고 있다.

프로세서의 "비용"은 다양한 파라미터를 사용하여 측정될 수 있다. 비록 많은 경우에는, 비용이 순수한 재정적인 것일 수 있지만, 많은 애플리케이션에서, 특히 내장형 프로세서 마켓에서는, 비용 계산은 또한 전력 소비, 냉각 요건, 효율 및 마켓으로 운반하는 시간과 같은 부수적인 고려사항을 더 포함한다.

임의의 프로세서가 유용한 기능을 수행하는 절대적인 능력은 획득가능한 MIPS(millions of instruction per second) 비율의 관점에서 특징지워질 수 있고, 따라서 임의의 프로세서의 "가격 대비 성능(price-performance ratio)"은 가령, MIPS/mm², MIPS/$, 또는 MIPS/mW의 관점에서 특징지워질 수 있다.

그러나 실제로는 모든 명령이 동일한 양의 유용한 작업을 성취하는 것은 아니므로, "순수한" MIPS 비율은 쉽게 비교가능하지 않다. 따라서, 디지털 신호 프로세서(DSP)는 휴대폰의 무선 인터페이스 부근의 수학적으로 강렬한 프로세싱을 해결하기에 매우 적합하지만, 전화의 스크린에서 실행되는 웹 브라우저를 실행할 때는 매우 비효율적이다. 실제로 이는 프로세서가 "이용가능한 애플리케이션" 가격 대비 성능의 관점에서 보다 유용하게 분류될 수 있음을 의미한다.

또한, 유효 성능의 부가적인 감소가 프로그래밍, 즉 특정 애플리케이션을 실행하도록 프로세서를 제어하고 커스터마이즈(customize)하는 데 사용되는 소프트웨어, 툴의 비효율에 의해 발생될 수 있다. 특정 애플리케이션에 대하여 프로세서로부터 추출될 수 있는 성능의 최종 레벨은 따라서 사용할 수 있는 즉, "획득가능한 애플리케이션에 이용가능한" 가격 대비 효율의 레벨로써 관측될 수 있다.

프로세서 애플리케이션에 이용가능한 가격 대비 효율을 향상시키기 위한 반도체 회사의 드라이브에 있어서, 새로운 계층의 프로세서, 즉 멀티코어 디바이스가 개발되어 왔다. 멀티코어 디바이스는 다양한 엘리먼트들(코어들)로 이루어진 상당히 집적된 프로세서이며, 상기 엘리먼트들 각각은, 프로세서에 의해 실행될 수 있는 애플리케이션의 특정 특징에 대하여 최대 레벨의 유용한 가격 대비 성능을 제공하기 위하여 상당히 특수화될 수 있다. 이러한 디바이스들은 "이종" 즉, 다중의 상이한 코어들을 통합하거나, "동종" 즉, 다중의 유사한 코어들을 통합하고 있을 수 있다.

대부분의 멀티코어 디바이스들은 또한 시스템온칩(SoC) 디바이스로써 분류될 수도 있는데, 이는 집적이 단지 다중 프로세싱 코어들만을 포함하는 것이 아니라 메모리, IO, 및 특정 제품에 대해 대부분의(전부가 아니면) 하드웨어 요건을 처리하기 위해 요구되는 다른 시스템 "코어들"도 포함하기 때문이다. 비록 모든 SoC 디바이스들이 다중 프로세싱 코어들을 가지는 것은 아니지만, 용어 다중 코어 및 SoC는 종종 혼용된다. 멀티코어 SoC의 좋은 예는 여러 휴대폰에서 발견될 수 있고, 휴대폰에서 우리는 무선 인터페이스를 실행하기 위한 하나 이상의 DSP를 포함하는 단일 프로세서와, 전화에서 사용자 애플리케이션을 실행시키기 위한 범용 프로세서를 발견할 수 있다.

멀티코어 디바이스의 출현은, 무어의 법칙 즉, 실리콘의 임의의 주어진 면적에 집적될 수 있는 트랜지스터의 수는 제조 프로세스의 향상에 기인하여 매 18개월마다 두 배씩 증가한다는 법칙에 의해 가능해져 왔다. 무어의 법칙은 따라서 보다 많은 개별 트랜지스터들이 실리콘 다이상의 임의의 주어진 면적에 집적될 수 있게 하며, 단일 피스의 실리콘상에 심지어는 보다 복잡한 디바이스를 제조하는 것을 기술적으로 그리고 경제적으로 실행 가능하게 한다. 등가적으로, 트랜지스터의 크기를 감소시킴으로써, 이들은 아무리 높은 속도에서도 스위칭될 수 있다.

역사적으로, 무어의 법칙은 기초가 되는 아키텍처에 대한 주된 변경(즉, 개선은 디바이스의 논리적인 매크로(macro) 아키텍처에 대한 것이 아닌 제조 프로세스와 디바이스의 물리적인 마이크로(micro) 아키텍처에서의 개선이다) 없이 새로운 세대의 프로세서를 사용된 실리콘의 관점에서 보다 빠르거나 보다 비용 효율적인 보다 작은 크기로 제조하기 위해 사용되어 왔다.

사실상, 멀티코어/SoC 프로세서로의 트렌드는, IO(통신) 기능성의 실리콘 다이 그 자체로의 도입과 함께 최초로 시작되었고; 이제는 IO, 메모리, 및 다중 프로세싱 유닛의 기능성, DSP 및 코프로세서는 동일한 실리콘 다이상에 집적될 수 있는 높은 레벨의 집적으로의 매크로 아키텍처의 전이로써 보여질 수 있다. 이러한 프로세서들은 특정 계층의 애플리케이션에 최저 비용, 최고로 수행하는 프로세서를 제공함으로써 최종 제품의 제조 비용을 감소시켜야 한다. 또한, 대부분의 시스템 컴포넌트들을 단일 프로세서상에 집적시킴으로써, 부분 개수가 감소될 수 있고, 따라서 신뢰성을 증가시키고 전력 소비를 감소시킬 수 있다.

주된 문제는 최고의 가능한 "애플리케이션에 이용가능한" 가격 대비 효율을 얻기 위하여 이러한 멀티코어 디바이스 내의 기초가 되는 하드웨어의 사용이 어떻게 최적화될 수 있는가이다.

프로세서 및 시스템 설계자들이 애플리케이션 소프트웨어 내부의 병렬성(parallelism)(애플리케이션 레벨 병렬성), 및 명령 스트림 내부의 병렬성(명령 레벨 병렬성)에 영향을 주는 여러 방법이 존재한다. 다양한 발현은 병행 입력이 관리되는 장소와, 시스템이 실행중인 때/"런타임"에 관리되는지(동적 시스템), 애플리케이션 소프트웨어가 컴파일되고 있을 때/컴파일 시간에 관리되는지(정적 시스템) 여부에 따라 다르다. 실제로, 동적 및 정적 시스템들 및 하드웨어 집약 및 소프트웨어 집약적인 솔루션 사이의 구분은 명백하지 않으며, 하나의 원리에 의한 기술들은 종종 서로로부터 차용된다.

개별 프로세싱 코어의 수준에서는, 병렬로 된 단일 스트림으로부터의 많은 명령에 대해 동작하는 다중 이슈 프로세서 또는 머신의 개념은 당업계에서 잘 성립되어 있다. 이들은 두 가지 기본적인 유형에 든다; 슈퍼스케일러(superscaler) 프로세서와, 훨씬 긴 명령어(VLIW) 프로세서. 슈퍼스케일러 프로세서는 런타임(동적으로 스케쥴됨) 또는 컴파일 타임(정적으로 스케쥴됨) 중 어느 하나에서 식별된 클록 사이클마다 변하는 수의 명령어를 발부한다. VLIW 프로세서는 고정된 수의 명령어를 발부하며, 컴파일러에 의해 정의된 훨씬 긴 명령어를 형성한다. 전형적으로, 프로그래머는 이 프로세스에 대해서 완전히 인식하고 있지 않은데, 이는 시스템의 프로그래밍 모델이 표준이며, 단일 프로세서 분리이기 때문이다.

슈퍼 스레딩 및 하이퍼 스레딩은 모두, 다중 가상 프로세서들 가운데 실행의 다중 스레드를 멀티플렉싱함으로써 다중 프로세서를 대리실행하는 기술이다. 전형적으로, 이러한 가상 프로세서들은 특정 리소스들을 공유하며, 이 리소스들은 통계적으로 모든 시간 동안 단일 스레드에 의해 사용되지 않을 것이다. 슈퍼 및 하이퍼 스레딩 아키텍처는 다중 독립 프로세서처럼 보이며 따라서 효율적으로 작업하기 위하여 존재하는 애플리케이션 병렬성의 레벨을 요한다. 일반적으로 프로세서 코어 내의 하드웨어 제한은 지원되는 스레드의 수를 실질적으로 100 미만으로 제한한다.

또한, 여러 시스템 아키텍처의 옵션들이 여러 애플리케이션에서의 고유의 병렬성의 개발을 위해 존재한다. 각 프로세서가 그 자신의 명령을 실행하며 일부 공유된 리소스(가령, 메모리 및/또는 인터커넥트)를 통해 그 피어와 협동하는 한편 그 자신의 데이터의 세트에 대하여 동작하는, 다중 명령 다중 데이터(MIMD) 머신은, 매우 다양한 애플리케이션을 어드레스할 수 있는 이들의 능력에 기인하여 대중화되었다.

성능 요구가 증가함에 따라, 내장 시스템은 요구되는 수준의 실리콘 효율을 전달하기 위하여, 다중의 상이한 또는 유사한 처리 리소스를 이용하여 멀티코어 MIMD 아키텍처를 점점 더 이용하고 있다. 일반적으로, 비록 보다 많은 애플리케이션에 특정된 하이브리드 아키텍처들이 또한 일반적으로 발견되지만, 이들은 집중된 공유 메모리 아키텍처를 호출한 MIMD의 클래스이다. 즉, 단일 어드레스 공간(또는 그 부분)이 다중 처리 리소스들 사이에 공유된다.

비록 MIMD 어레이의 각각의 처리 리소스는 명령어 레벨 병렬성(ILP)을 이용하지만, MIMD 머신은 기초가 되는 하드웨어의 잠재적 성능을 실현하기 위하여 스레드 레벨 병렬성(TLP)의 이점을 취할 수도 있다. (특정 하드웨어에 의한) 런타임시에 또는 (최적화하는 컴파일 툴에 의한) 컴파일-타임시에 구체화되는 ILP와는 반대로, TLP는 애플리케이션 설계시에 하이레벨 프로그래밍 소프트웨어 내부에서 정의된다.

스레딩(threading)은 병렬성의 하이 레벨 표현으로써 여러 해 동안 소프트웨어 커뮤니티 내에서 사용되어 왔던 개념이다. 스레드는, 정의에 의해 다른 스레드와 동시에 실행할 수 있는, 실행 상태, 명령 스트림 및 데이터 세트를 포함하는 작업의 독립 패키지를 정의한다. 명령 스트림의 복잡성은 중요하지 않다. 스레드는 데이터의 단순한 전달에서부터 복잡한 수학적 변환에 이르기까지 무엇이든 기술할 수 있다.

전통적으로 운영 시스템들은, 소프트웨어 엔지니어들이 기초가 되는 디바이스 아키텍처의 상세한 이해를 필요로 하지 않고 애플리케이션이 멀티코어 아키텍처의 특정 구조에서 실행될 수 있게 해주는 스레드 할당 기능을 포함하는 시스템 관리의 제공을 도와 왔다. 그러나, 현존하는 유니코어(uni-core) 디바이스 내의 스레드 관리용 소프트웨어 기술은 일관적인 방법으로 멀티코어 아키텍처에 쉽게 적응될 수 없다. 데이터에 대한 솔루션은 독점적이었고, 디자인 기초에 의해 디자인에 대한 주문된 솔루션을 요하며, 일반적으로 성능과 비례축소가능성(scalability)을 타협해 왔다.

역사적으로, 이종 멀티코어 시스템(즉, 광범위하게 상이한 처리 리소스들을 갖는 시스템)의 경우에, 많은 변하는 접근법들이 이종의 처리 리소스들을 함께 작업할 수 있게 하려고 채용되어 왔다. 그러나, 넓게는 이들은 다음의 두 카테고리 - "프록시 호스트"와 "협동적인(co-operative)"("피어 투 피어"로도 알려짐)으로 분리될 수 있다. 전자의 경우에, 지정된 범용 호스트 프로세서(여기서, 버스 기반의 시스템이 CPU라고 종종 불리워짐)는 시스템 전반을 지배하며, 태스크들을 시스템을 가로질러 중개하며 메모리 및 디바이스와 같은 리소스들에 대한 액세스를 동기화한다. 이러한 시스템 감독은 일반적으로 운영 시스템 커널(kernal)에서 동작되며 시스템 애플리케이션과 시간의 부분 및 호스트 프로세서에서의 비동기 이벤트의 처리를 경쟁한다. 다시 말해서, 이러한 범용 프로세서는 멀티코어 디바이스용의 모든 처리 리소스에 대하여 집중된 프록시 스레드 관리자처럼 행동할 뿐만 아니라 주된 애플리케이션 프로세서로써 행동해야 한다.

이러한 구성에서 사용될 때, 일반적인 프로세서는 미리 정의된 스케쥴링 방침, 즉 이들의 우선순위에 따라서, 각각의 처리 리소스에 대하여 실행할 준비가 된 스레드의 큐(즉, 디스패치 큐 또는 준비된 큐)를 유지할 뿐만 아니라, 이들 자신이 실행되기 시작하기 전에 일부 이벤트, 즉 다른 스레드의 결과의 리턴을 기다리는 스레드의 큐(즉, 계류중인 큐 및 타이밍 큐)도 또한 유지해야 한다. 다른 시스템 오버헤드들 외에도 이러한 것들은 스레드 실행 이전의 프로세서 구성과 같은 것이다.

범용 프로세서가, 가령 스레드의 완결(및 따라서 그 스레드를 막 완결했던 처리 리소스의 자유화)에 기인하여 발부된 인터럽트의 결과로써 현재 실행하고 있는 스레드로부터 시스템의 감독(스레드 관리 포함)으로 그 처리 시간을 전환할 때마다, 일반적인 프로세서는 콘텍스트(context) 변경을 해야 한다.

콘텍스트 변경은, 메모리 내에서 정지되고 있는 스레드의 현재 진행을 저장하는 것, 다른 스레드/처리 리소스의 서비스를 위한 감독 루틴에 관한 명령을 가져오는 것, 그 후 임의의 구성 요건을 포함하는 그러한 명령들을 실행하는 것을 포함한다. 추가적인 콘텍스트 변경은 원래의 정지된 스레드로의 리턴을 실행해야 한다. 이러한 콘텍스트 변경은 일반적으로 인터럽트의 수신시에 실행되며, 내장된 시스템에서는, 이러한 인터럽트는 종종 빈번하며 범용 프로세서에서 실행하는 애플리케이션 코드와 비동기이다. 따라서, 시스템은 전체로써 현저한 성능의 열화를 나타낸다. 콘텍스트 스위치는 또한 호스트 프로세서 캐쉬의 유효성에 부정적인 영향을 미친다(소위 "콜드-캐쉬" 효과).

협동적인(co-operative) 시스템의 경우에, 각 처리 리소스는 그 일부가 리소스간 통신을 가능하게 하는 운영 시스템의 개별 인스턴스를 실행한다. 이러한 배열은 따라서 피어들 사이에 인터럽트의 특정 발송의 결과로써, 비교적 엄격한 아키텍처의 파티셔닝(partitioning)을 갖는다. 비록 이러한 유형의 시스템이 애플리케이션을 제조하는 데 필요한 프리미티브를 제공하지만, 수행의 성능은 여전히 운영 시스템 커널 액티비티와 연관된 빈번한 콘텍스트 스위치를 겪는다.

요약하면, 전통적인 아키텍처(범용 프로세서, 소프트웨어 집행부 등)에서의 시스템 관리의 실현을 위한 현재의 설계 및 방법론은 복잡한 이종 멀티코어 아키텍처의 시스템 및 스레드 관리에 부적절하다. 사실 범용 프로세서는 마이크로(명령 세트) 및 마크로(캐쉬, 레지스터 파일 관리) 아키텍처의 레벨 모두에서 열악하게 최적화된다. 비록 멀티코어 프로세서의 인터커넥트가 개별 처리 리소스들 사이의 연동을 위한 물리적인 매체를 제공하지만, 시스템 관리로의 코히어런트(coherent) 접근을 가능하게 하는 모든 처리 리소스들 사이에 공유되는 시스템 와이드(system wide) 태스크 관리 및 통신 층이 존재하지 않는다. 최악의 경우에, 이에 의해 전통적으로 애드혹(ad-hoc) 기반으로 소프트웨어에서 개별적으로 해결되어야 하는 모든 처리 리소스 사이의 모든 가능한 통신 채널과 연관된 독특한 문제에 이르게 된다.

따라서, 이러한 매우 복잡한 멀티코어 아키텍처의 효율적인 시스템 관리 방법에 대한 필요성이 존재한다. 소프트웨어 추출만으로는 복잡한 멀티코어 아키텍처의 필요한 레벨의 성능을 제공할 수 없다.

본 발명의 제1 측면에 의하면, 청구항1에서 정의된 멀티코어 프로세서를 위한 리소스 관리 및 태스크 할당 제어기가 제공된다.

바람직한 실시예에서, 청구항1의 제어기는 리소스 관리 및 태스크 할당에 전용되며 추가적인 프로세싱 리소스를 제공하지 않는다.

본 발명의 실시예에서, "전통적인" 마스터 프로세싱 유닛(즉, 본 발명의 리소스 관리 및 태스크 할당 제어기의 부재시에는 태스크 할당뿐만 아니라 이용가능한 프로세싱 리소스들 중 하나로써 작용할 일반적인 프로세싱 리소스)은, 리소스 관리 및 태스크 할당 제어기가 개시 시퀀스 동안 MPU로부터 마스터 상태를 가정하면, 마스터로써 시스템 개시를 시작할 것이다.

본 발명의 실시예들은 또한 특정 태스크를 처리하는 데 사용하기 위해 무시될 수 있었던 프로세싱 리소스로 태스크를 할당할 수 있게 하는 이종 멀티코어 프로세서에 대한 기능을 제공한다. 이러한 방법으로, 본 발명의 제어기는 이용가능한 리소스의 보다 효율적인 사용을 가능하게 한다.

개별 리소스 관리 및 태스크 할당 제어기를 제공함으로써, 본 발명은 멀티코어 프로세서용의 개선된 태스크 할당 및 관리 시스템을 제공하며, 이용가능한 프로세싱 리소스들 사이에서 보다 효율적인 태스크 할당을 가능하게 한다. 제어기는 시스템 관리 및 예외 처리의 엘리먼트들을 전용의, 효율적인, 하드-코딩된 실시예로 추출해낸다.

본 발명의 실시예는, "프록시 에이전트"의 역할을 강요하지 않고, 제어기와 함께 제어기 클라이언트를 채용한다. 제어기 클라이언트는 하드웨어나 소프트웨어로 구현될 수 있다. 이러한 배치는 기초가 되는 시스템의 "런타임" 액티비티를 효율적으로 마스터한다. 특히, 제어기는 미리 정의된 할당 파라미터의 범위에 기초하여 시스템 스레드 상태 및 스케쥴링 결정의 정확함을 연속적으로("탐욕스럽게") 유지한다.

바람직한 실시예의 아키텍처는 이에 따라서 구성 컴포넌트들과 개별 프로세싱 리소스들의 자율과의 사이에서 작업의 분리 관점에서 복잡성과 무관하게 현저한 이점을 제공한다. 모든 프로세싱 리소스들은 슬레이브(slave) 디바이스가 되며, 이는 디폴트 "레이지(lazy)"에 의하며, 즉 이들은 태스크를 수행하기 위하여 리소스 관리 및 태스크 할당 제어기에 의해, 바람직한 실시예에서는, 전용의 인터럽트를 통해 명료하게 지시받기를 기다린다. 균등하게, 다른 실시예에서는, 폴(poll) 기반의 통신이 리소스 관리 및 태스크 할당 제어기 및 프로세싱 리소스 사이에서 사용될 수 있다.

본 발명의 제어기를 채용하는 시스템에서, 핀을 통해 직접적으로 또는 프로세싱 리소스들(즉 입출력 디바이스) 중 하나의 외부 조작을 통해 간접적으로 중 어느 하나로서, 아키텍처 외부로부터 발생된 모든 비동기 이벤트는 바람직하게는 제어기로 라우팅되며, 여기서 이들은 "부팅 시간"에 구성된 한 세트의 스케쥴링 방침 들을 이용하여 타깃 프로세싱 리소스상의 현재 실행중인 태스크와 비교된다. 프로세싱 리소스는, 외부 이벤트와 연관된 인터럽트 서비스 스레드(IST)가 현재 실행중인 트랜잭션(스레드 또는 태스크)을 관장한다면, 유일하게 인터럽트되며, 이에 의해 당업계의 문제였던 임의의 프로세싱 리소스에서의 불필요한 콘텍스트 스위칭을 제거한다. 또한, 바람직한 실시예의 제어기 클라이언트에 의해, 임의의 복잡성을 갖는 프로세싱 리소스가 공유된 리소스 및 제어기 그 자체에서 기본적인 시스템 관리 동작을 수행할 수 있고(스레드를 생성하고, 동기화 프리미티브를 발부하고, 스레드를 삭제하고, 메모리 복사 등), 명령어 세트 기반의 머신이 이러한 태스크를 프록시에 의해 실행할 필요를 회피하게 된다.

본 발명의 추가적인 측면에서는, 이러한 제어기를 포함하는 멀티코어 프로세서가 제공된다.

본 발명은 또한 청구항 40에서 정의된 것처럼 멀티코어 프로세서에 리소스를 할당하고 제어하는 방법으로 연장된다.

추가적인 이점 및 특징은 본원에 첨부된 종속항에 정의되어 있다.

본 발명은 다양한 방법으로 실시될 수 있고, 일부 실시예는 단지 예시적인 방법으로 다음의 첨부된 도면을 참조하여 기재될 것이다:
도1은 본 발명의 일 실시예에 따라서 리소스 관리 및 태스크 할당 제어기를 통합하고 있는 시스템의 논리적 배치의 개략 블록도를 도시한다;
도2는 도1의 논리적 배치의 일 예시적인 구현의 개략 블록도를 도시하며, 본 발명을 구현하는 제어기는 전용 메모리 디바이스 및 제어기 클라이언트와 함께 범용의 멀티코어 프로세서 아키텍처 내부에 통합된다;
도3은 도2의 엘리먼트들을 통합하는 콘템퍼러리(contemporary) 시스템온칩(SoC) 버스 기반의 아키텍처의 일예를 블록도 형식으로 도시한다;
도4는 도1 내지 도3의 제어기로의 외부 접속의 보다 상세한 도면이다;
도5는 도2 및 도3의 메모리 디바이스의 보다 상세한 도면이다;
도6은 도2 내지 도4의 제어기의 내부 구성의 보다 상세한 도면이다;
도7a는 도2 및 도3에 도시된 제어기 클라이언트의 개략적인 블록도이다;
도7b는 다중 처리 리소스용 프록시로써 작용하는 단일 제어기 클라이언트의 경우에 시스템의 개략적인 블록도를 도시한다;
도8은 하드웨어 제어기 클라이언트의 보다 상세한 개략적인 블록도이다;
도9a 및 도9b는 속(generic) 기술자(descriptor) 및 이의 연관된 필드를 도시한다;
도9c 및 도9d는 스레드 기술자 및 이의 연관된 필드를 도시한다;
도9e 및 도9f는 스케쥴러 층 기술자 및 이의 연관된 필드를 도시한다;
도9g 및 도9h는 디스패치 큐 기술자 및 이의 연관된 필드를 도시한다;
도9i 및 도9j는 계류중인 큐 기술자 및 이의 연관된 필드를 도시한다;
도9k 및 도9l은 스킵 리스트 기술자 및 이의 연관된 필드를 도시한다;
도10은 스레드 기술자, 시스템 관리 제어기, 처리 리소스 및 공유된 시스템 메모리 사이의 일반적인 관계를 도시한다;
도11은 도10의 배치에서 부정(indirection)의 원리를 도시하며, 두 개의 상이한 처리 리소스가 존재한다;
도12는 도4의 제어기 내의 스레드 관리의 일반적인 개관을 도시한다;
도13은 일반적인 계류중인 큐 구조를 도시한다;
도14는 일반적인 계류중인 큐 스킵 리스트를 도시한다;
도15는 일반적인 타이머 큐를 도시한다;
도16은 두 개의 처리 리소스에 대한 일반적인 준비된 큐 구조를 도시한다;
도17은 일반적인 단일 디스패치 큐 구조의 예시적인 실시예를 도시한다;
도18은 스레드 번들링을 포함하는 두 개의 층 스케쥴링 계층구조를 도시한다;
도19는 통신 시스템에서 공통적으로 발견될 수 있는 예시적인 간략화된 큐 구조를 도시한다.

도1은 본 발명의 실시예에 따른 특징을 통합하고 있는 시스템 프레임워크(10)의 논리적 개관이다. 프레임워크(10)는 다수의 처리 리소스(150)를 포함하며, 각각의 처리 리소스는 처리 리소스(150)의 다른 것들과 유사할 수도 있고 유사하지 않을 수도 있으며, 임의의 복잡성을 가진다. 각각의 처리 리소스는 공통의 시스템 메모리(140)로의 액세스를 공유하며, 공유되는 데이터는 인터커넥트(160)를 경유하여 공통의 시스템 메모리(140)에 저장된다. 물론, 모든 시스템 메모리(140)가 모든 처리 리소스(150)에 반드시 공통되지는 않는다는 것이 이해될 것이다.

시스템 프레임워크는 또한 본 발명의 실시예에 따른 집중된 업무 할당 및 관리 시스템(20)을 포함한다. 집중된 업무 할당 및 관리 시스템(20)은, 시스템 관리 제어기(130)와, 타이트하게 연결된 전용 메모리(190)에 접속되는, 타이트하게 연결된 전용 메모리 인터페이스(180)를 포함한다. 각각의 처리 리소스(150)는 인터커넥트(115)를 경유하여 제어기(130)에 액세스할 수 있다. 어떠한 특정 인터커넥션 전략도(즉, 제어기(130)가 각각의 처리 리소스(150)와 그리고 그 역으로 통신하는 배치, 및 각각의 처리 리소스(150)가 시스템 메모리(140)와 통신하는 배치) 도1의 배치의 실행에 필요하지 않음이 이해될 것이다; 특히, 점대점 링크, 중앙 시스템 버스 또는 심지어는 파이프 라이닝된 아키텍처가 균등하게 채용될 수 있고, 각각의 처리 리소스가 직접적 또는 간접적으로(즉, 다른 처리 리소스를 경유하거나 다른 방식으로) 제어기(130)와 통신할 수 있어야 한다는 것만을 덜게 된다.

도2는 단지 예시적인 방법으로 도1의 논리적 배치를 실행하는 멀티코어 프로세서를 도시한다. 도2의 멀티코어 프로세서는 다수의 처리 리소스(150)를 채용하며, 각각의 처리 리소스는 시스템 인터커넥트(160)를 경유하여 접속된다. 시스템 인터커넥트(160)는 입력 인터페이스(100), 출력 인터페이스(110)를 경유하여 시스템 관리 제어기와 통신한다. 도2의 예에서, 시스템 인터커넥트(160)는 각각의 처리 리소스들(150)을 서로와 연결하고 제어기(130)와 연결하며, 또한 시스템 메모리(140)와 같은 공유된 시스템 리소스와 연결하는 전통적인 중앙 버스로써 배치된다. 메모리(140)와의 인터페이싱은 다수의 현재 이용가능한 기술들 중 어느 하나를 통해 이루어질 수 있다. 메모리는 현재 이용가능한 중앙 컴퓨터 메모리 기술들 중 어느 것, 가령 정적 랜덤 액세스 메모리(SRAM), 또는 이중 데이터 레이트 랜덤 액세스 메모리(DDR RAM)로 이루어질 수 있다.

도2에 도시된 것처럼, 각각의 멀티코어 처리 리소스(150)는 중앙 제어기(130)로부터 제어 정보를 수신하고 수신된 제어 정보에 따라 처리 리소스(150)를 관리하도록 구성된, 연관 시스템 관리 제어기 클라이언트(120)를 갖는다. 제어기 클라이언트(120)의 기능 및 목적은 이하에 도7 및 8과 관련하여 보다 상세히 기재된다. 각각의 처리 리소스는 시스템 인터커넥트(160)를 통해 제어기(130)와 통신하기 위한 연관된 인터커넥트 에이전트(170)를 또한 가진다. 인터커넥트 에이전트(170)는 제어기 클라이언트(120)에 대한 일반적인 인터페이스를 제공하며, 제어기 클라이언트는 시스템 인터커넥트(160)상에서 사용중인 아래에 놓인 인터커넥트 프로토콜과 독립적이다(즉, 이는 시스템 인터커넥트(160)상에서 사용중인 통신 프로토콜과 제어기 클라이언트(120)에 의해 사용중인 통신 프로토콜 사이에 프로토콜 변환을 제공한다). 인터커넥트 에이전트(170)의 사용으로 인해, 본 발명의 실시예들의 제어기 클라이언트들(120)은 현재 이용가능한 임의의 시스템 인터커넥트 프로토콜과 더불어 사용될 수 있다.

멀티코어 프로세서는, 전체로서, 스레드라 불리는 다수의 개별 작업으로 분할될 수 있는 타깃 애플리케이션을 실행하도록 구성된다. 각각의 처리 리소스(150)는, 문제되는 스레드의 우선순위, 각 처리 리소스(150)의 이용가능성, 및 특정 처리 리소스의 특정 스레드의 실행에 대한 적합성을 포함하나 이에 제한되지는 않는 다수의 파라미터에 따라 제어기(130)에 의해 적절한 스레드를 할당받는다. 이것은 아래에서 보다 상세히 다시 기재될 것이다.

그러나, 시스템 관리 제어기(130)와 이 전용 메모리(190)의 부가는 달리 프로세서(10)의 레이아웃의 재설계를 요하지 않는다는 것이 이해되어야 한다.

한 가지 특정 배치는 도3에 도시되어 있는데, 도3은 전형적인 시스템온칩(SoC) 아키텍처를 블록 다이어그램 형식으로 도시하며, 실제 애플리케이션에서의 제어기(130)의 리소스 관리하에서 배치될 수 있는 다양한 처리 리소스를 도시하고 있다. 처리 리소스는 DSP와 같이 비교적 범용성을 가질 수도 있고, 주변기기 IO와 같이 비교적 제한된 기능성을 가질 수도 있음이 인식될 것이다.

시스템 관리 제어기 인터페이스 그룹

도4는 제어기(130)와 제어기(130)의 주변에 위치된 이의 연관된 인터페이스 그룹(200-250)을 도시하고 있다.

시스템 제어 그룹(200)은 시스템 관리 제어기(130)의 정확한 동작을 보장하기 위해 요구되는 두 개의 시스템 입력 신호를 포함한다. 두 개의 시스템 입력은 시스템 클록에 연결된 CLK 입력과, RST 입력을 포함한다. 시스템 관리 제어기(130)로부터의 모든 출력 신호들은 시스템 클록에 동기(同期)이며, 시스템 관리 제어기(130)로의 모든 입력 신호들은 이 클록을 이용하여 샘플링된다. RST 입력은 시스템 관리 제어기(130)를 리셋하기 위한 동기 리셋 신호이다.

외부 인터럽트 그룹(210)은 시스템 관리 시스템 외부로부터 소싱(source)되는 동기 외부 인터럽트의 그룹으로 구성된다. 이러한 신호들은 시스템 관리 제어기(130) 주변으로의 이들의 부착 이전에 CLK에 동기화되어야 한다. 외부 인터럽트 그룹(210)에서의 신호들은 가령, 외부 세계와의 입력 인터페이스를 통하거나, 외부 멀티코어 프로세서로부터 핀을 경유하여 직접 유도될 수 있다. 외부 인터럽트 입력의 수는 멀티코어 프로세서(10) 설계 단계 동안 정의된다.

내부 제어 그룹(220)은 각 제어기 클라이언트(120)에 대한 단일 동기 인터럽트 및 이와 연관된 처리 리소스(150)로 이루어진다. 따라서, 신호의 그룹의 수는 일반적으로 시스템 내의 처리 리소스(150)의 수와 일반적으로 상응할 것이며 멀티코어 프로세서(10) 설계 단계 동안 정의될 것이다. 내부 인터럽트 신호는 실행의 준비가 된 스레드를 나타내며, 제어기 클라이언트(120)와 연관된 특정 처리 리소스(150)에 할당되고 있다.

타이트하게 연결된 메모리 인터페이스 그룹(180)은 시스템 관리 제어기(130)를 그 자신의 전용의 타이트하게 연결된 메모리 리소스(190)로 인터페이싱한다. 도5는 전용의 타이트하게 연결된 메모리(190)의 전형적인 구조를 도시한다. 어드레스 경로 및 데이터 경로의 폭은 멀티코어 프로세서(10) 설계 단계 동안 정의된다. 전용의 타이트하게 연결된 메모리 인터페이스는 메모리 어드레스 버스(191), 메모리 판독 데이터 버스(192), 메모리 기록 데이터 버스(193), 및 기록(194) 및 판독(196) 인에이블 신호를 포함한다.

부착된 메모리는 동기 SRAM 디바이스라고 가정한다. 전용의 타이트하게 연결된 메모리(190)는 타깃 애플리케이션의 필요에 따라서 멀티코어 프로세서(10) 설계 단계 동안 정의되는, 정수 개수의 제어기 메모리 엘리먼트들(195)을 포함한다. 현재의 바람직한 실시예에서, 각각의 제어기 메모리 엘리먼트들(195)은 256비트의 메모리 공간을 소비한다. 다시 현재의 바람직한 실시예에서, 제어기는 최대 65536의 제어기 메모리 엘리먼트들(즉, 16Mb 메모리)을 지원한다. 이후에 기재될 큐 기술자가 제어기 메모리 엘리먼트들(195)을 소비하지만, 일반적인 시스템에서 필요한 제어기 메모리 엘리먼트들(195)의 수는 스레드 지원 요건에 의해 지배될 것이다. 예를 들어, 시스템 관리 제어기(130) 내에서 400개의 스레드를 동시에 지원할 수 있는 시스템은 약 128kb의 부착된 메모리를 필요로 할 것이다.

도4의 인터커넥트 인터페이스 그룹(230)은 멀티코어 프로세서(10) 내에 사용되는 선택된 인터커넥트 프로토콜 및 멀티코어 프로세서 설계 단계 동안 정의되는 인터커넥트 에이전트(170)에 따른다.

제어기 서브블록 설명 및 함수

도6은 시스템 관리 제어기(130)의 주된 논리 컴포넌트들을 도시하고 있다. 제어기(130)의 기능성은 다음의 기능을 수행하는, 네 개의 주된 내부 평행 처리 서브블록으로 분리된다:

1. 스레드 입력 관리자(TSIM)(300) : 전용의 타이트하게 결합된 메모리(190) 내의 빈 제어기 메모리 엘리먼트들(195)의 리스트를 유지하고, 제어기 메모리 엘리먼트들(195) 복구를 감시하도록 구성된다.

2. 스레드 동기화 관리자(TSPM)(310) : 전용의 타이트하게 연결된 메모리(190) 내에 계류중인 리스트와 타이머 큐를 유지하고 스레드들 사이에 동기화를 수행하고, 필요할 때, 전용의 타이트하게 연결된 메모리(190) 내의 준비된 큐 구조로 스레드의 촉진을 실행하도록 구성된다. 스레드 동기화 관리자(310)는 전용의 타이트하게 연결된 메모리(190) 내부에 계류중인 스레드 기술자의 삽입 및 추출을 통해 계류중인 타이머 큐 구조의 무결성을 유지한다.

3. 스레드 출력 관리자(TSOM)(320) : 전용의 타이트하게 연결된 메모리(190) 내에 준비된 큐 구조들과, 전용의 타이트하게 연결된 메모리(190) 내에 각 처리 리소스(150)용 디스패치 큐(Dispatch queues)들을 유지하도록 구성된다. 스레드 출력 관리자(TSOM)(320)는 또한 제어기 클라이언트(120)로 보내지는 인터럽트(220)를 발생시키도록 구성된다. 준비된 큐 구조의 무결성의 유지보수는 전용의 타이트하게 연결된 메모리(190) 내에, 제어기 메모리 엘리먼트들(195) 내에 유지되는 스레드 기술자들의 삽입 및 추출에 의해 수행된다.

4. 스레드 스케쥴 관리자(TSSM)(330) : 전용의 타이트하게 연결된 메모리(190) 내의 준비된 큐 구조들 내부에 각 처리 리소스(150)용 스케쥴링 결정을 제공하도록 구성된다.

부가적으로 다수의 제2의 처리 서브블록들이 지원 기능들을 제공한다:

5. 스레드 메모리 관리자(TSSM)(340) : 상호 배타(exclusivity) 및 록킹(locking)을 포함하는, 부착된 전용의 타이트하게 연결된 메모리(190)로의 집합적 액세스를 제공하도록 구성된다.

6. 인터럽트 관리자(TSIC)(350) : 들어오는 외부 시스템 인터럽트를 내부의 동기화 프리비티브(primitive)들로 변환하도록 구성된다.

7. 시간 관리자(TSTC)(360) : 동기화 목적을 위한 타이머 기능과 각 처리 리소스(150)에 대한 감시단(watchdog) 타이머 기능성을 제공하도록 구성된다.

8. 시스템 인터페이스(TSIF)(380) : 멀티코어 처리 리소스(150)로의 인터커넥트 인터페이싱 및 구성 및 런타임 액세스를 제공한다.

이제 시스템 관리 제어기(130) 내부의 상기 제1 및 제2 처리 서브블록의 상호작용의 상세한 기재가 이어진다.

각 서브블록은 다른 서브블록에 대한 한 세트의 기능을 제공하며, 이에 의해 각각의 서브블록이 전용의 타이트하게 연결된 메모리(190) 내에 있는 이들 각각의 유지되는 구조들에 대한 조작을 실행하도록 그 피어들(peers)에게 지시할 수 있게 된다. 기능들은, 제어기 소프트웨어 애플리케이션 프로그래밍 인터페이스(API)에서 수신한 유사한 명령을 수신시, 특정 서브블록에 의해 호출된다.

스레드 입력 관리자 기능:

스레드 입력 관리자(300)는 시스템 관리 제어기(130) 내의 다른 서브블록들에 대해 세 개의 공공 기능을 제공한다.

FreeListStatus 기능은 제어기 메모리 엘리먼트(195) 프리(free) 리스트 내에 있는 엘리먼트들의 수와 헤드 포인터를 리턴한다. 프리 리스트는 현재 사용되지 않는 제어기 메모리 엘리먼트들(195)의 리스트이다. 이 기능은 제어기(130) 소프트웨어 API에 있는 유사한 명령을 수신할 때, 시스템 인터페이스(380)에 의해서만 호출될 수 있다.

PushFreeIndex 기능은 자유로워진 제어기 메모리 엘리먼트(195) 인덱스를 프리 리스트로 되돌리기 위해 사용된다. 이 기능은 스레드 스케쥴 관리자(330)에 의해서만 호출될 수 있다.

PopFreeIndex 기능은 프리 리스트로부터 프리 제어기 메모리 엘리먼트(195) 인덱스를 팝(pop)하기 위해서 사용된다. 이는 일반적으로 시스템 인터페이스(380) 내에 있는 API 호출 서비스 루틴 내로부터 호출된다.

스레드 동기화 관리자 기능:

스레드 동기화 관리자(310)는 일곱 가지 공공 기능을 시스템 관리 제어기(130) 내에 있는 다른 서브 블록들로 제공한다.

다음의 다섯 가지 기능들은 제어기(130) 소프트웨어 API에 의해 수신되는 유사한 명령에 응답하여, 시스템 인터페이스(380)에 의해서만 호출된다.

PushPendingDescriptor 기능은 계류중인 큐 기술자를 계류중인 큐 기술자의 리스트에 부가하기 위하여 부트 프로세스 동안 사용된다.

PushThread 기능은 주어진 계류중인 큐에 종속 스레드를 부가하기 위해 런타임 동안 사용된다.

SetTimerStatus 기능은 타이머 큐 내에 있는 엘리먼트들의 수와 헤드 포인터를 설정한다.

GetTimerStatus 기능은 타이머 큐 내에 있는 엘리먼트들의 수와 헤드 포인터를 리턴한다.

SetPendingStatus 기능은 계류중인 큐 기술자 리스트의 상태를 설정한다.

GetPendingStatus 기능은 계류중인 기술자 큐 내에 있는 엘리먼트들의 수와 헤드 포인터를 한다.

SyncEvent 기능은 주어진 계류중인 큐에 동기화 프리미티브를 발부하기 위해 사용된다. 이 기능은 스레드 인터럽트 관리자(350) 및 시스템 관리 제어기(380)에 의해 호출된다.

TimeEvent 기능은 타이머 큐에 타이머 기반의 동기화 프리미티브를 발부하기 위해 사용된다. 이 기능은 시간 관리자(360)에 의해서만 호출된다.

스레드 출력 관리자 기능:

스레드 출력 관리자(320)는 시스템 관리 제어기(130) 내에 있는 다른 서브 블록에 다섯 개의 공공 기능을 제공한다.

푸쉬 기능은 스레드 기술자를 준비된 큐 구조 내에 배치한다. 본 방법은 처리 속도를 촉진하기 위하여(예를 들어, 인터럽트를 처리하기 위하여) 높은 우선순위으로 호출될 수 있다. 스레드가 독립적인 경우(즉시 준비되는 경우) 호출은 시스템 인터페이스(380)로부터 이루어질 것이며, 스레드 기술자가 최초에 종속성을 가졌다면 호출은 스레드 동기화 관리자(310)로부터 이루어진다.

다음의 세 가지 기능은 제어기(130) 소프트웨어 API에 있는 유사한 명령의 수신에 응답하여, 시스템 인터페이스(380)에 의해서만 호출될 수 있다.

GetDispatchQueueStatus 기능은 디스패치 큐 리스트 내에 있는 엘리먼트들의 수와 헤드 포인터를 리턴한다.

SetDispatchQueueStatus 기능은 디스패치 큐 리스트 내에 있는 엘리먼트들의 수와 헤드 포인터를 리턴한다.

DispatchQueuePop 기능은 디스패치 큐의 헤드로부터 스레드 기술자를 팝(pop)한다.

DispatchWorkQueuePush 기능은 디스패치 큐를 스레드 출력 관리자(320) 작업 큐로 푸쉬(push)한다. 이 기능은 스레드 스케쥴 관리자(330)에 의해서만 호출될 수 있으며, 스레드 스케쥴 관리자는 이 기능을 사용하여 스케쥴 업데이트의 결과로써 디스패치 큐 내부에 요구되는 변경을 출력 관리자(320)에게 통지한다.

스레드 스케쥴 관리자 기능:

스레드 스케쥴 관리자(330)는, 시스템 관리 제어기(130) 내부에 위치된, 스레드 출력 관리자(320) 및 시스템 인터페이스(TSIF)(380)에 세 개의 공공 기능을 제공한다.

Pushups 기능은, 스레드 기술자를 준비된 큐 구조에 더한 바로 직후, 스레드 출력 관리자(320)에 의해 호출된다.

PushPopWorkEvent 기능은, 스레드 기술자를 준비된 큐 구조로부터 제거한 바로 직후, 스레드 출력 관리자(320)에 의해 호출된다.

Freelndex function은 제어기 메모리 엘리먼트(195)의 해방(liberation)이 스레드 스케쥴 관리자(330) 내부에서 진행하는 액티비티를 스케쥴링하는 것과 적절히 동기화될 수 있게 한다. 호출은 제어기(130) 소프트웨어 API에서 유사한 명령의 수령시에 발부될 수 있거나, 스레드 출력 관리자(320) 내부에 있는 팝 동작의 결과로써 발부될 수 있다.

제어기 클라이언트

전술한 것처럼, 용어 처리 리소스(150)는 명령이 얼마나 근본적인가에 관계없이, 명령을 실행할 수 있는 임의의 리소스에 적용된다. 따라서, 고정된 기능을 갖는 리소스들, 가령 입출력 모듈도 포함된다. 처리 리소스(150)의 유형에 따라서, 시스템 관리 코어 클라이언트(120)를 통한 시스템 관리 제어기(130)와 처리 리소스(150) 사이의 접속은 단방향 또는 양방향의 어느 하나일 수 있다.

도7은 시스템 관리 제어기(130)와 더불어 사용하기 위한 제어기 클라이언트(120)의 예시적이고 개략적인 블록도를 도시한다.

적절한 처리 리소스(150), 가령 범용 프로세서 또는 디지털 신호 처리기에 대하여, 제어기 클라이언트(120)는 일반적으로 소프트웨어로 구현될 것이다. 그러나, 처리 리소스(150)가 제한된 기능을 갖는 경우, 제어기 클라이언트(120)는 하드웨어 컴포넌트를 요할 수 있다.

*하드웨어 컴포넌트가 시스템 인터커넥트(160)와 처리 리소스(150) 사이에 사용될 때, 제어기 클라이언트(120)는 여전히 동일한 인터페이스를 사용하여 처리 리소스(150)를 인터페이싱한다. 다시 말해서, 제어기 클라이언트는 인터커넥트 에이전트(170)에 대하여 제어기 클라이언트에 대한 처리 리소스(150)의 것과 동일한 인터페이스를 제공한다. 일부 경우에는, 처리 리소스로의 데이터 경로를 처리 리소스로부터의 데이터 경로와는 구별된 것으로 다루는 것이 적절하다(가령 입출력 디바이스의 경우).

제어기 클라이언트(120)는 주된 인터페이스에 부가하여, 디버그 이벤트 및 런타임용 출력으로써 사용하기 위한 대역을 벗어난(out of band) 인터페이스들을 또한 제공한다. 소프트웨어 제어기 클라이언트(120)가 사용되는 경우, 이들은 적절한 서비스 루틴을 호출하는 표준 인터럽트를 이용하여 제공된다.

동작의 제어기 클라이언트 모드 :

각 제어기 클라이언트(120)는 완전히 인터럽트 구동된다. 제어기(130)로부터 내부 인터럽트를 수신시, 제어기 클라이언트(120)는 전용의 타이트하게 연결된 메모리(190) 내에 유지되는 특정 처리 리소스(150)와 연관된 디스패치 큐의 헤드로부터 스레드 기술자를 팝한다. 그 후 스레드 기술자 내부의 특유의 레퍼런스가 사용되어 주 메모리 리소스(140)로부터 스레드 제어 정보, 스레드 제어 블록(TCB)을 추가적으로 판독한다. TCB내에 포함된 정보는 다음 중 어느 하나일 수 있다:

1. 제어기 클라이언트(120) 구성 콘텐츠. 이 정보는 제어기 클라이언트(120) 시스템 리소스 사용 방침, 데이터 프리젠테이션 모드, 등을 구성하기 위해 사용된다.

2. 처리 리소스(150) 구성 콘텐츠. 이는 특정 스레드의 실행을 위한 처리 리소스(150)를 준비하기 위해 요구되는 정보이다. 이는 이러한 스레드의 이전의 부분적인 실행으로부터의 복구 또는 오디오 코덱과 같은 스페셜리스트 하드웨어 가속기의 구성을 포함한다.

3. 명령 콘텐츠. 고정 기능 하드웨어 가속기의 경우에, "명령"은 타깃으로 된 하드웨어 처리 리소스(150), 가령 처리 리소스(150)가 출력 모듈일 때의 출력 명령에 내재할 것이며, 임의의 요구되는 분화 또는 구성이 구성 정보 내부에 채용될 것이다. 소프트웨어 제어기 클라이언트(120)의 관점에서, 이는 일반적으로 스레드와 연관된 기능 코드에 대한 포인터일 것이다.

4. 데이터 콘텐츠. 이 콘텐츠는 시스템 메모리(140) 내의 시작 어드레스 또는 다중 어드레스와 스레드가 동작하는 데이터의 범위를 정의할 수 있다.

5. 제어기 클라이언트(120) 처리 후 콘텐츠. 이 콘텐츠는 스레드 실행의 완료 후에 제어기 클라이언트(120)의 행동을 결정한다.

제어기 클라이언트(120)의 세 가지 구분된 동작의 단계가 존재한다:

1. 구성 단계: 처리 리소스(150)와 제어기 클라이언트(120)가 특정 스레드의 실행을 준비한다. 가장 간단한 경우에 구성 단계는 널(null)일 수 있다.

2. 실행 단계: 스레드는 실행되고 있고 제어기 클라이언트(120)는 데이터를 지지하고 있고/있거나 리소스 이용을 모니터링하고 있다.

3. 완료 단계: 처리의 완료는 행동 없음, 다른 스레드의 생성, 동기화 프리미티브의 발부, 또는 스레드 생성과 동기화의 조합으로 귀결될 수 있다. 또한, 제어기 클라이언트(120)는 스케쥴러 메트릭을 설정 또는 업데이트하고 스레드를 종결하기 위해 요구될 수도 있다. 스레드의 실행 동안, 추가의 메모리가 결과를 저장하기 위해 요구되는 경우에, 제어기 클라이언트(120)는 이 방법을 또한 실행해야 한다.

개별 하드웨어 제어기 클라이언트(120b)가 능동 주기 동안 이용가능한 시스템 인터커넥트(160) 대역폭을 완전히 이용하는 환경에서, 최적화된 솔루션은 제어기 클라이언트(120b)가 다중 하드웨어 처리 리소스(150)에 대한 프록시로써 동작하게 할 수 있다. 그러한 배치는 도7b에 도시된다. 이전의 경우에서 처럼, 프록시 제어기 클라이언트(120b)는 인터럽트 구동되지만, 이전의 예에서는 하나의 인터럽트만이 제어기(130)로부터 라우팅된 반면, 프록시 제어기 클라이언트 모델에서는, 처리 리소스(150)마다 인터럽트가 존재한다. 제어기(130)로부터 수신된 인터럽트의 인덱스에 따라서, 프록시 제어기 클라이언트(120b)는 식별된 처리 리소스(150)에 대하여 동일한 단계를 실행한다. 시스템 인터커넥트(160) 사용 방침이 요구되는 프록시 제어기 클라이언트 모델에 있어서, 하드웨어 어댑터(120c)는 처리 리소스(150)와 시스템 인터커넥트(160) 사이에 머무를 것이다.

전술한 것처럼, 제어기 클라이언트(120)는 소프트웨어로 구현될 것이다. 이 경우, 제어기 클라이언트(120)의 기능성의 일부(가령, 공유된 리소스 이용 방침)는 일반적으로 이미 처리 리소스(150) 하드웨어(가령, 메모리 관리 유닛(MMU))에 존재할 수 있는 기존 하드웨어 컴포넌트를 이용할 것이다.

결과적으로, 소프트웨어 제어기 클라이언트(120) 아키텍처 및 구현은 처리 리소스(150)에 특정적이다.

하드웨어 제어기 클라이언트(120)는 연관된 처리 리소스(150)의 특이성에 따라서 스페셜리스트 요건을 가질 수도 있다. 다음의 섹션은 대부분의 경우에 적합할 범용 아키텍처를 기술한다.

하드웨어 제어기 클라이언트의 일반적인 예

하드웨어 제어기 클라이언트(120)의 기본적인 구조는 도8에 도시된다. 제어기 클라이언트 유한상태기계(Finite State Machine; FSM)(500)는 설계의 기능적인 중심부에 있다. 이 유한상태기계(FSM; 500)는 모든 세 단계 동안 활성일 수 있다. 제어기 클라이언트 FSM(500)은 제어기(130)로부터의 인터럽트(220)에 의해 활성화된다.

최초로 제어기 클라이언트 FSM(500)은 시스템 인터커넥트(160)를 마스터링(mastering)하여, 그 자신의 명령에 대한 레퍼런스를 포함하는 공유된 메모리 리소스(140)로부터 TCB를 판독한다. 구성 단계 동안, 제어기 클라이언트(120)는, 구성 명령들을 해석하고 이들을 처리 리소스(150)에 발부된 기록 사이클로 번역하는 처리 리소스 인터페이스를 마스터링한다. 또한, 제어기 클라이언트(120)는 그 자신의 리소스 방침을 구성한다. 구성 상태로부터 실행 상태로 천이하는 방식은 처리 리소스(150)에 특정적일 수 있지만, 명시된 실행 프리미티브에 의해 표시되거나 단지 데이터 전달 상태로의 진입일 수 있다.

제어기 클라이언트(120) 개략도로부터 가장 간단한 아키텍처는 처리 리소스(150) 및 시스템 측 모두에 동일한 인터페이스 프로토콜을 가진다. 이 경우, 실행 단계 동안, 처리 리소스(150) 판독 및 기록 사이클은 적절한 곳을 체크하면서 시스템 인터페이스에 단순히 교차 맵핑된다.

가장 간단한 제어기 클라이언트(120) 구현은 시스템에서 처리 리소스(510)로의 경로와 처리 리소스로부터 시스템(520)으로의 경로 모두에 FIFO 스타일의 인터페이스를 요할 것이다. 이러한 본질을 갖는 제어기 클라이언트(120)의 실행 단계 동안, 데이터는 메시지 또는 스트리밍 모드에 의해 처리 리소스(150)에 제공될 수 있다. 전체 데이터 세트가 처리 이전에 제어기 클라이언트(120) 내에 국부적으로 누적되는 메시지 모드는, 보다 복잡한 인터커넥트 중재자를 용이하게 하는 보다 개략적인 그레인 블록의(grain blocky) 인터커넥트 거동을 발생시킨다. 데이터가 시스템 메모리로부터 처리 리소스(150)로 직접 스트리밍되는 스트리밍 모드는, 주고받기(hand-shaking)에 대한 보다 주의 깊은 고려를 요하며, 미세한 그레인의 인터커넥트 트랜잭션 및 인터커넥트 성능으로의 타이트한 결합을 나타내는 보다 많은 실리콘 유효 솔루션을 제공한다.

실행 단계로부터 완결 단계로의 전이는 데이터의 처리 리소스(150)로의 제공을 측정함으로써 추론될 수 있거나, 또는 처리 리소스(150) 그 자체에 의해 명시적으로 시그널링될 수 있다. 완결 단계 동안, 제어기 클라이언트(120)는 최초의 스레드 제어 블록에 의해 제공된 명령의 집합으로부터 다시 한번 실행한다.

일부 경우에는, 처리 리소스(150)로의 데이터 경로(가령 입출력 디바이스) 및 처리 리소스(150)로부터의 경로를 구별하여 처리하는 것이 적절함에 주의하여야 한다. 반대로, 일부 경우(가령 DSP와 같은 알고리즘 가속기)에는, 동일한 제어기 클라이언트(120) 프레임워크 내에 있는 데이터의 소비자와 생산자를 결합하는 것이 자연스러울 것이다.

처리 리소스(150)와 다른 시스템 리소스 사이의 연결해제의 레벨을 제공하기 위하여, 많은 부가적인 편의가 제어기 클라이언트(120)에 의해 제공될 수도 있다:

a) 처리 리소스(150)에 의해 생성된 어드레스는 비교기(530) 및 비교 어드레스 레지스터(540)를 이용함으로써, 기본 어드레스 및 오프셋 정의에 의해 정의된 예측된 거동에 대하여 체크될 수 있다.

b) 처리 리소스(150)에 의해 생성된 어드레스는, 감산기(subtractor)(550) 및 오프셋 어드레스 레지스터(560)를 이용함으로써 오프셋될 수 있고, 처리 리소스(150)가 일반적으로 어드레스 0ㅧ0에 대하여 정규화된, 임의의 주어진 스레드에 대한 어드레스 맵의 정규화된 뷰(view)를 갖게 할 수 있다.

객체

시스템 관리 제어기(130) 내부에서 사용되는 데이터유형의 예는 공공(대게 시스템으로부터 가시적이며 시스템에 의해 조작됨) 가시성(visibility) 및 비밀(시스템 관리 제어기(130)에 의해서만 가시적이며 시스템 관리 제어기(130) 서브블록에 의해서만 조작됨) 가시성으로 나누어진다. 다중 단부(multiple end) 애플리케이션을 가로지르는 설계의 휴대성을 보장하기 위하여, 모든 스레드, 큐 및 집합된 큐 기술자들은 공통 기반의 클래스, 제어기 메모리 엘리먼트(195)를 이용하여 전용의 타이트하게 연결된 메모리(190) 내부에 저장된다.

제어기 메모리 엘리먼트들

각각의 제어기 메모리 엘리먼트들(195)은 일곱 가지 기술자 유형들 중 어느 하나를 나타낸다:

1. 프리 리스트 엘리먼트. 이 엘리먼트는 다른 기술자 유형들 중 어느 하나에 의해 이용하기 위해 비어 있다. 사용자 초기화 또는 런타임 조작이 불필요하다.

2. 스레드 기술자(TD). 이는 애플리케이션/OS 스레드를 대표하는 데이터 구조이다. 이 기술자는 전용의 타이트하게 연결된 메모리(190) 내의 계류중인 큐, 준비된 큐 또는 디스패치 큐 중 어느 하나에 존재한다. 사용자 초기화는 불필요하지만, 런타임 조작이 요구된다.

3. 스케쥴 루트 기술자(SRD). 이는 스케쥴러 계층구조의 최상단 기술자이다. 사용자 초기화가 요구되지만 런타임 조작은 불필요하다. 루트 기술자는 페어런트(parent)를 가지지 않지만, 차일드(children)는 SSTD, DSTD, 또는 TD중의 어느 하나일 수 있다.

4. 정적 스케쥴러 층 기술자(SSTD). 이는 페어런트가 SRD 또는 다른 SSTD 중의 어느 하나인 정적인 스케쥴러 층 기술자이다. SSTD의 차일드는 다른 SSTD, DSTD 또는 TD 중의 어느 하나일 수 있다.

5. 동적 스케쥴러 층 기술자(DSTD). 이는 동적 스케쥴러 층 기술자이다. 사용자 초기화는 불필요하지만, 런타임 조작이 요구된다. DSTD의 페어런트는 SRD 또는 SSTD 중 어느 하나일 수 있으나, DSTD는 TD 차일드만을 가질 수 있다.

6 디스패치 큐 기술자. 이 유형의 기술자는 연관된 처리 리소스(150)로부터의 팝 동작을 기다리고 있는 스레드 기술자의 리스트를 기술한다. 사용자 초기화는 요구되지만, 런타임 조작은 불필요하다.

7. 계류중인 큐 기술자. 이 유형의 기술자는 동기화 이벤트를 기다리고 있는 스레드 기술자의 리스트를 기술한다. 사용자 초기화는 요구되지만, 런타임 조작은 불필요하다.

이러한 기술자들은 다음 섹션에서 보다 상세히 기재된다.

제어기 메모리 엘리먼트들(195)의 다양한 형태와, 이들 각각이 도9a 내지 9l에 도시되어 있다.

스레드 표현

기술자가 초기화 또는 런타임 조작을 요하는 경우, 동작은 제어기(130) API를 통해 행해진다. 집중된 태스크 할당 및 관리 시스템은 실시간 상호작용이 하드웨어 구현에 적합함/극단적으로 간단함을 보장하도록 설계된다.

도10은 스레드 기술자, 시스템 관리 제어기(130), 처리 리소스(150) 및 공유된 시스템 메모리(140) 사이의 일반적인 관계를 도시한다. 각각의 스레드 프리미티브는 특유의 레퍼런스, pReference를 포함한다. 이 레퍼런스는 시스템 관리 제어기(130)에 의해 해석되거나 수정되지 않는다. pReference는 실행될 태스크를 정의하는 시스템 메모리(140) 내의 데이터 구조에 대한 포인터를 제공한다. 일반적으로 이는 제어기 클라이언트 제어 블록(125)일 수 있고, 다음의 엘리먼트들을 적어도 포함할 수 있다: (처리 리소스 명령 블록(145)으로써 도10에 도시된) 기능 포인터, (데이터 블록(135)으로써 도10에 함께 도시된) 스택 포인터 및 아규먼트(argument) 포인터. 공유된 시스템 리소스에 대한 대역 내의 구성 또는 보안을 제공하는 부가적인 필드가 정의된다.

그러나 애플리케이션 및/또는 타깃 처리 리소스(150)에 따라서, 제어기 클라이언트 제어 블록(125)의 복잡성이 변할 수 있다. 특히, 주어진 적절한 "제어" 명령 코드 및 대응하는 "데이터 경로" 코드에 의해 이종의 처리 리소스(150)가 특정 환경하에서 동일한 데이터에 대해 동일한 기능을 실행할 수 있는 추가적인 레벨의 사기(indirection)가 포함될 수 있음에 주의하여야 한다.

도11은 스케쥴링 계층구조 부하(load)가 두 개의 상이한 처리 리소스(도11의 유형Ⅰ 및 유형Ⅱ)(150a 및 150b)를 교차하여 태스크를 균형 맞추는 예를 도시한다. (이 계층구조로 큐잉(queuing)되는 스레드 기술자 내부의) pReference 필드는, 각각의 상이한 명령 집합에 의해 요구되는 특정 명령 스트림에 대응하는 각 유형의 처리 리소스에 대한 포인터가 존재하는 점을 제외하고는, 이전처럼 제어기 클라이언트 제어 블록(125)을 참조한다. 제어기 클라이언트(120)는 제어기 클라이언트 제어 블록(125) 내에 있는 플래그에 따라서 적절한 명령 스트림(명령 블록 145a 또는 145b)을 선택한다.

이 특징은 가령 특정 처리 리소스의 파워-다운 특징과 결합하면 유용할 수 있다. 주어진 태스크에 대한 최적의 프로세서가 파워 다운되는 경우, 희생이 큰 재부팅 사이클을 초래하느니 부차적인 최적의 프로세서가 태스크를 실행하는 것이 바람직할 수 있다.

또한, 예외적인 부하들 하에서, 가령 많은 부하가 있는 DSP에 대한 짐을 더는 것이 적게 부하가 걸리는 범용 프로세서를 가능하게 할 수 있다.

처리 리소스(150)는 스레드를 처리할 준비가 된 경우, 그 처리 리소스(150)와 유일하게 연관된 적절한 디스패치 큐로부터 팝 된다. 팝 동작은 pReference를 포함하는 객체, 스케쥴링 이벤트로 귀결되는 스케쥴러 메트릭, 및 스레드가 타임아웃 또는 동기화 프리미티브에 기인하여 준비가 되었는지 여부의 표시를 포함하는 한 세트의 플래그들을 리턴한다. 스레드 기술자용으로 사용되는 제어기 메모리 엘리먼트(195)는 미래의 스레드 기술자에 의한 사용을 위해 프리 리스트로 자동적으로 리턴된다.

공공 객체

이 섹션은 제어기(130) API를 통해 시스템에 가시적인 객체를 기술한다. 일반적으로 이러한 객체는 런타임에 제어기(130)와 클라이언트(120)와 이들의 연관된 처리 리소스(150)를 포함하는, 집중된 태스크 할당 및 관리 시스템에 의해 조작된다.

런타임 제어기(130) API에 의해, 애플리케이션은 새로운 스레드를 도입하거나, 새로운 동적 스케쥴러 엘리먼트들을 도입하거나, 동기화 프리미티브를 발부하거나, 스케쥴링된 스레드를 팝하거나, 선취된 스레드를 푸쉬하거나, 스레드를 제거할 수 있다.

도12는 시스템 관리 제어기(130) 내에 있는 스레드 관리의 일반적인 개관을 도시한다.

스레드 프리미티브

스레드 프리미티브의 포맷은 도9c 및 도9d에 도시되어 있다. 그 종속성에 따라서, 스레드 기술자는 계류중인 큐 구조에 배치되거나 준비된 큐 구조로 직접 배치될 수 있다. 만약 스레드가 계류중인 큐 구조 내에 배치될 것이라면, 애플리케이션은 스레드의 종속성을 정의하여야 한다. 외부 이벤트에 대한 종속은 그 자신을 종속성 레퍼런스로서 증명한다. 제어기(130)는 이러한 종속성 레퍼런스를 해석하지 않는다; 이는 스레드 기술자가 언제 준비된 큐 구조로 전이할 것인지를 결정하기 위하여 들어오는 동기화 프리미티브에 대한 비교를 위하여 유지된다.

종속 스레드에 대하여 널 종속성 레퍼런스와 결합한 타임아웃이 구체화될 수 있고 이러한 설비는 스레드 기반의 하드웨어 타이밍 설비로써 사용될 수 있다. 종속성 레퍼런스와 무관하게 타임아웃은 스레드가 특정 시간에 스케쥴링되도록 한다.

스레드들은 이들을 준비된 큐 구조로 촉진되도록 하는 동기화 이벤트(타이머 또는 프리미티브)에 따라서 태그된다.

동기화 프리미티브

동기화 프리미티브는 계류중인 큐와 인터페이싱하며 계류중인 큐 구조로부터 준비된 큐 구조로의 하나 이상의 스레드 기술자의 전이를 일으킨다.

각각의 동기화 프리미티브는 식별된 계류중인 큐 구조에 있는 각각의 스레드 기술자 내에 저장된 종속성 레퍼런스와 비교되는 유일한 레퍼런스를 포함한다. 비교는 스레드 프리미티브에 의해 식별된 우선순위의 순서로 계속된다.

그 유형에 따라서, 동기화는 가장 높은 우선도와 매칭되는 스레드 기술자 또는 계류중인 큐 내에 있는 모든 매칭되는 스레드 기술자 중 어느 하나를 웨이크(wake)한다. 또한 특수한 브로드캐스트 프리미티브는 모든 계류중인 큐 내에 있는 모든 매칭되는 스레드를 웨이크한다.

인터럽트 처리

인터럽트 서비스 스레드(IST) 방법은 비동기 이벤트에 의해 처리 리소스(150)에 부과되는 부하를 최소화하는 가치있는 수단을 제공한다. 또한, 본 발명에 기초한 시스템에서의 가속된 실시간 응답은 보다 소수의 시스템 수정과 함께 보다 광범위한 IST의 사용을 가능하게 한다.

제어기(130)는 제어기 주변장치에 대한 외부 인터럽트 입력(210)으로부터 동기화 프리미티브를 자동적으로 생성한다. 계류중인 큐 내에 있는 미리 구성된 인터럽트 서비스 스레드 기술자는 이러한 인터럽트 동기화 프리미티브의 수신시에 준비된 큐 구조로 촉진될 것이다.

애플리케이션은 통상적으로 시스템 초기화 시에 외부 인터럽트(210)와 연관된 스레드 기술자를 구성하고 연관된 인터럽트 서비스 스레드의 각각의 실행 동안 다시 구성할 것이다.

이러한 설비는 시스템 내의 임의의 다른 전용의 인터럽트 서비스 처리 리소스(150)에 대한 필요성을 효율적으로 제거한다. 또한, 이는 이러한 외부 인터럽트(210)를 동일한 우선순위 구조를 통하여 그리고 모든 프로세서 태스크에 대하여 사용되는 동일한 방침에 따라서 처리하며, 보다 높은 우선순위 태스크를 이미 실행하고 있는 처리 리소스 내부의 콘텍스트(context) 스위치에 대한 필요성을 배제한다. 임의의 수의 내포 인터럽트들은 현재 실행중인 스레드를 통상의 선취 루틴을 이용하여 준비된 큐로 다시 푸쉬하는 능력에 의해 지원된다.

타이머 기반의 인터럽트(와치독 및 주기적 이벤트)는 유사한 방법으로 다루어진다. 시간 기반의 태스크(주기적 또는 1회성)는 타이머 큐에 삽입되어야 하며 타임아웃 종속성을 갖는 스레드와 유사한 방식으로 다루어진다. 설계에 의해, 이러한 방법은 유용한 처리 요건을 갖지 않는 시간 기반의 예외를 배제한다.

인터럽트 우선순위는, 빠른 응답 시간 동안 인터럽트 루틴이 현재 실행중인 태스크를 선취하게 허용되도록, 설정될 수 있다.

비밀 객체

비밀 객체는 일반적으로 부팅 시간, 즉 전력 다운 사이클 이후의 시스템 초기화 동안 구성된다. 처리 리소스(150)는 런타임 동안 내부 객체와는 직접 상호작용하는 경우가 드물다.

내부 객체는 우선 큐잉하는 구조이다. 시스템 관리 제어기(130)는 네 개의 주된 유형의 큐, 계류중인 큐, 타이머 큐, 준비된 큐, 및 디스패치 큐를 관리한다.

부가적인 제2의 큐는 내부의 동작을 용이하게 하기 위하여 시스템 관리 제어기(130) 내부에 존재한다. 큐들 사이의 스레드 기술자의 이동은 단지 포인터 조작과 함께만 발생한다. 스레드 기술자는 결코 복제되지 않는다.

계류중인 큐 구조

*스레드는 계류중인 큐 구조로부터 준비된 큐 구조로 동기화 이벤트 또는 타이머 이벤트 중 어느 하나를 통해 촉진된다. 스레드는 이러한 클래스의 이벤트 모두 또는 단지 하나에 민감할 수 있다. 스레드가 모두에 민감한 경우에, 스레드는 계류중인 큐 와 타이머 큐 모두에 제공된다.

계류중인 큐는 동기화 이벤트를 기다리고 있는 종속적인 스레드를 유지한다. 스레드는 처리 리소스(150)로부터의 동기화 프리미티브를 통하거나, 시간 관리자(360)에 의해 내부적으로 발생되는 타이머 이벤트에 의해서 이러한 구조로부터 제거된다. 구성가능한 수의 계류중인 큐는 다중 쟁탈 범위와 인터럽트 서비스 스레드를 지원하기 위하여 애플리케이션 프로그래머에게 이용가능하다; 각 계류중인 큐 내부의 엘리먼트들은 이들의 우선순위에 따라 처리되어야 한다. 우선순위에 따라 처리하는 것에 대한 두 가지 대안 - 삽입에 대한 정렬(sort on insert)과 추출에 대한 정렬(sort on extration) - 이 존재한다. 삽입에 대한 정렬은 계류중인 리스트가 엄격한 우선순위 순서로 저장되는 프로세스를 정의하며 새로운 스레드가 이들의 우선순위에 따라 리스트 내부의 위치로 삽입된다. 추출에 대한 정렬은 새로운 스레드를 삽입하는 장소의 임의의 선택을 수행하며 동기화 후에 적격의 스레드 기술자의 우선순위 기반의 정렬을 수행한다. 본원의 바람직한 실시예는 삽입에 대한 정렬 기법을 수행한다.

도13은 계류중인 큐의 일반적인 구조를 도시한다. 엔트리는 엄격한 우선순위 순서로 저장된다. 새로운 스레드의 삽입이 성취되는 속도는 스킵 리스트의 사용에 의해 가속되며, 도14는 일반적인 계류중인 큐 스킵 리스트를 도시한다.

전술한 것처럼, 스레드는 동기화 또는 타이머 이벤트를 기다리는 동안 차단될 수 있다. 몇몇 스레드는 배타적으로 동기화 이벤트를 기다리고 있을 것이며, 유사하게 몇몇 스레드는 배타적으로 타이머 이벤트를 기다리고 있을 것이다. 각 경우에, 스레드는 단일 큐 내에만 존재할 것이다. 각각의 스레드는 두 세트의 포인터들을 포함하며, 이들은 계류중인 큐와 타이머 큐 모두와 명목상으로 연관된다. 이들 경우에, 공급된 타이머 큐와 계류중인 큐 포인터들은 각각 여분이다. 스킵 리스트는 이러한 여분의 포인터를 이용할 수 있다 - 가령, 만약 스레드가 타이머 큐에 나타나지 않는다면, 이러한 포인터들은 계류중인 큐에서의 가능한 앞선 점프를 지시하기 위하여 재사용될 수 있다. 이는 그렇지 않다면 연속된 서치가 스레드 기술자의 블록을 점프할 수 있도록 하는 반면, 새로운 종속 스레드의 정확한 삽입 포인트에 반복적으로 접근한다.

대안은 스킵 노드 기술자이며, 이의 일예는 그 연관된 필드(도9l)와 함께 도9k에 도시된다. 스킵 노드 기술자는 미리 정의된 메트릭에 따라서 계류중인 큐 구조와 타이머 큐 구조에 주기적으로 삽입된다. 스킵 노드 기술자는 스킵 노드 기술자들 또는 관여하는 스레드 기술자들 사이에 있는 스레드 기술자의 정의된 최대 관측된 수에 따라서 삽입된다. 스킵 노드 기술자들은 계류중인 큐의 일부와 타이머 큐 스킵 리스트를 동시에 형성할 수 있다.

각각의 새로운 종속하는 스레드는 그 우선순위에 따라 삽입되어야 한다. 프로세스는 일반적으로 새로운 스레드의 우선순위가 스킵 리스트 노드의 것보다 더 클 때까지 스킵 리스트를 횡단함으로써 개시될 것이다. 그 후, 정확한 삽입 포인트가 발견될 때까지 스레드 기술자 기초에 의해 스레드 기술자에 대한 그 스킵 리스트 노드로부터의 서치가 계속될 것이다. 이는 선형 서치가 새로운 종속 스레드에 대한 정확한 삽입 포인트를 자동추적할 때 계류중인 스레드의 블록들을 스킵하는 것을 가능하게 한다.

동기화 이벤트는 세 가지 구별된 유형을 가진다:

유니캐스트: 동기화 이벤트는 특정 계류중인 큐에서 발견된 제1(가장 높은 우선순위)의 적절한 종속 스레드에 대한 상태 전이를 개시한다.

멀티캐스트: 동기화 이벤트는 특정 계류중인 큐에서 모든 적절한 종속 스레드에 대한 상태 전이를 개시한다.

브로드캐스트: 동기화 이벤트는 모든 계류중인 큐에서 모든 적절한 종속 스레드에 대한 상태 전이를 개시한다.

계류중인 큐는 도9i 및 9j에 도시된 것처럼, 계류중인 큐 기술자에 의해 정의된다. 계류중인 큐 기술자는 일단 시스템 초기화 동안 구성되고 단일 제어기 메모리 엘리먼트(195)를 소비한다. 계류중인 큐는 종속 스레드 기술자만을 포함하며 리스트 노드를 스킵한다.

타이머 큐 구조

타임아웃 이벤트를 기다리고 있는 스레드 기술자를 저장하는 단일 시스템 와이드 타이머 큐가 제공된다. 도15는 타이머 큐의 예시적인 실시예를 도시한다.

스킵 리스트는 또한 전술한 것처럼 타이머 큐 구조로의 스레드의 삽입을 촉진하기 위해서도 사용된다. 그러나 이 경우에 스킵 리스트용으로 사용되는 임시적인 종속성(존재하는 경우)을 가지기만 하는 것은 스레드이다.

타이머 큐 기술자는 레지스터 내에 저장되어 동반 비교가 타이머 큐의 헤드와 현재 시간 사이에서 진행될 수 있게 한다. 이는 메모리 대역폭상의 타이머 똑딱거림(tick)의 충격을 크게 감소시킨다.

준비된 큐 구조

준비된 큐 구조는 실행할 준비가 된 스레드들을 유지한다. 이러한 스레드들은 독립 스레드 프리미티브와 함께 생성되었거나, 이들이 종속하는 동기화 프리미티브를 수신했다. 동기화된 스레드들은 계류중인 큐 구조로부터 이전에 전이했다.

준비된 큐 구조들은 스케쥴러 노드 기술자와 독립적이며 동기화된 스레드 기술자들을 포함할 수 있다. 스레드 기술자와 동적 스케쥴러 층 기술자들은 실시간으로 왕복하도록 허용되지만, 구조는 대게 시스템 초기화 동안 정의된다.

준비된 큐들은 특정 처리 리소스(150) 또는 처리 리소스(150)의 풀(pool)로 스레드를 스케쥴링한다. 이에 의해, 다중 처리 리소스(150)를 교차하여 부하 균형이 가능한 한편, 특정 처리 리소스(150), 가령 하드웨어 가속기 또는 입출력 디바이스에서의 특정 태스크들을 표적으로 하는 능력을 유지할 수 있다.

도16은 두 개의 처리 리소스(150)에 대한 일반적인 준비된 큐 구조를 도시한다. 동적 스케쥴러 층(2)은 루트 스케쥴러 층들 모두에 이용가능함에 주의하여야 한다. 이에 의해, 시스템 관리 제어기(130)가 루트 층(1 및 2)과 연관된 처리 리소스들(150) 사이에서 동적층(2) 아래의 균형 스레드를 로딩될 수 있다.

스케쥴러 층( tier )들

스케쥴러 층들은 스레드 기술자들을 스케쥴링하기 위해 사용되는 계층구조를 정의한다. 각각의 스케쥴러 층은 스케쥴링 알고리즘, 스케쥴링 판단을 결정하기 위해 사용되는 일부 메트릭들, 및 추가의 스케쥴러 층들 또는 스레드 기술자들일 수 있는 차일드 엘리먼트들의 리스트를 일반적으로 정의한다. 세 가지 유형의 스케쥴러 층 기술자; 루트, 정적 및 동적이 존재한다. 스케쥴러 층 메모리 엘리먼트들의 포맷은 도9e 및 9f에 도시되어 있다.

루트 스케쥴러 기술자들은 디스패치 큐들과 일대일 매핑을 갖는다. 이들은 준비된 큐 구조에 있는 최종 노드를 나타낸다. 스케쥴러 루트 기술자들은 시스템 초기화 동안 정의되며 영구히 존재한다.

정적 스케쥴러 기술자는 스케쥴링 계층구조에서 루트 노드 아래에 존재한다. 정적 스케쥴러 기술자의 페어런트는 다른 정적 스케쥴러 기술자 또는 루트 기술자일 수 있다. 이들은 이들의 페어런트의 정의된 스케쥴러 알고리즘 및 이들의 스케쥴러 메트릭에 따라서 자매 노드(sibling node)와 경쟁한다. 정적 스케쥴러 기술자는 시스템 초기화 동안 정의되며 영구히 존재한다. 동작 동안에, 시스템 관리 제어기(130)는 선택된 스케쥴링 알고리즘, 가령 라운드 로빈(Round Robin) 스케쥴링에 따라서 스케쥴러 메트릭을 유지한다.

동적 스케쥴러 기술자는 스케쥴링 계층구조에서 루트 및 가능한 정적 노드 아래에 존재한다. 동적 스케쥴러 기술자의 페어런트는 정적 스케쥴러 기술자 또는 루트 기술자 중 어느 하나일 수 있다. 이들은 이들의 페어런트의 정의된 스케쥴러 알고리즘 및 이들 자신의 스케쥴러 메트릭에 따라서 자매 노드와 경쟁한다. 동적 스케쥴러 기술자는 언제든지 정의될 수 있고 특정 환경하에서 물러날 수 있다. 이에 의해, 시스템은 순수하게 정적인 제공에서 가능한 것보다 훨씬 큰 수의 스케쥴링 층을 지원할 수 있다. 시스템 관리 제어기(130)는, 비록 모든 시간에 대해서 큰 수 및 스레드들의 차이 및 동적 스케쥴러 층들이 사용되지만, 한정된 기간 동안에는 일시적인 요구는 보다 작다는 가능성을 이용함으로써 이를 성취한다. 예를 들어, 최대 4000 동적 엘리먼트들(스레드 및 동적 스케쥴러 기술자)을 지원하는 부착된 메모리를 갖는 네트워킹 시스템에서, 임의의 순간에 16000 접속을 지원하는 것이 가능할 수 있고, 전체적인 접속 공간의 일부만으로부터의 데이터 유닛이 제어기에 상주할 것이다. 이 유연성은 성능에서의 작은 페널티에 의해 성취되는데, 이는 만약 동적 스케쥴러 기술자가 존재하지 않는다면, 이는 차일드 스레드 기술자의 부가 이전에 생성되어야 하기 때문이다.

동작 동안에, 시스템 관리 제어기(130)는 선택된 스케쥴링 알고리즘에 따라서 스케쥴러 메트릭들을 유지한다. 특정 환경 하에서, 동적 스케쥴러 기술자들은 제어기 메모리 엘리먼트(195) 프리 리스트로 다시 해방될 것이다. 이는 동적 스케쥴러 층 기술자 내에 있는 그 층 내에서 처리될 최종 스레드로부터 pReference를 저장함으로써 성취된다. 제어기(130) API는 동적 스케쥴러 기술자가 이후의 유사한 스레드들 사이에서 존속했는지 여부를 결정하기 위하여 제어기 메모리 엘리먼트들(195)의 호출을 지원한다.

디스패치 큐

디스패치 큐들은 연관된 처리 리소스(150)로부터 선입선출(FIFO) 큐 대기 서비스에서 스케쥴링된 스레드 기술자들을 유지한다. 현재의 바람직한 실시예에서는, 최대 32 디스패치 큐가 허용된다. 디스패치 큐는 도9g 및 9h에 도시된 디스패치 큐 기술자에 의해 정의된다. 디스패치 큐 기술자는 시스템 초기화 동안 구성된다.

준비된 큐 구조로부터 디스패치 큐 구조로 전이하고 있는 스레드 기술자의 프로세스는 하드웨어로 수행되며 제어기(130) API 상호 작용을 요하지 않는다.

도17은 본 발명의 특징을 구현하는 전형적인 단일 디스패치 큐 구조의 예시적인 실시예이다. 디스패치 큐 기술자는 전체 임계점(full threshold)을 정의한다. 디스패치 큐 길이는 스레드 번들이 스케쥴링되거나 선취된 스레드 푸쉬가 발생하는 전체 임계점을 초과하도록만 허용된다.

엘리먼트들은 처리 리소스에 의해 제어기(130) API를 통해 호출된 팝 동작을 통해 디스패치 큐로부터 제거된다.

우선순위 필드는 디스패치 큐 기술자 내에 포함된다. 스레드가 디스패치 큐로부터 팝될 때, 우선순위 필드는 현재 실행중인 스레드의 우선순위과 함께 존재한다. 추가적인 API 호출은 우선순위가 우선순위 반전을 피하기 위하여 실행중인 프로세서에 의해 다른 값으로 리셋될 수 있게 한다. 우선순위 반전은 상이한 우선순위를 갖는 적어도 3개의 스레드를 포함하며 동기화와 스케쥴링 요건 사이의 충돌을 기재한다. 우선순위 반전은 보다 낮은 우선순위 스레드가 보다 높은 우선순위 스레드를 무한히 차단할 수 있게 한다. 예를 들어, 낮은 우선순위 스레드는 공유된 리소스를 록킹한 후, 보다 높은 우선순위 스레드에 의해 선취된다. 보다 높은 우선순위 스레드는 그 후 낮은 우선순위 스레드에 의해 록킹된 리소스를 차단한다. 이제 높은 우선순위 스레드가 차단되기 때문에, 통상적으로 낮은 우선순위 스레드가 회복하며, 록킹된 리소스로부터 독립적이며 이제 자유롭게 실행할 수 있는 제3의 매체 스레드에 대한 것이 아니다. 낮은 우선순위 스레드는 공유된 리소스를 언록킹할 기회를 얻지 않으며 따라서 높은 우선순위 스레드는 무한히 차단된다. "우선순위 한도(ceiling)" 프로토콜은, 스레드가 공유된 리소스를 소유하는 한편 특정 우선순위에서 실행된다는 것을 의미한다. 이는 위에서 정의된 "낮은" 우선순위 스레드가 "높은" 우선순위를 가정하는 한편 높은 우선순위 스레드와 공유된 리소스를 소유함을 보장한다.

스레드 번들은 동일한 스케쥴러 층으로부터 발생하는 스레드 기술자의 그룹을 기술한다. 파라미터는, 스케쥴링 결정이 업데이트하도록 강제되기 전에 준비 큐의 그 층으로부터 디스패치 큐로 전이될 수 있는 스레드의 수를 정의하는 각각의 스케쥴러 기술자에 존재한다. 이러한 능력을 이용하고, 스케쥴러 층의 멤버가 공통점(commonality)을 공유하도록 배치함으로써, 처리 리소스(150)는 관측될 것보다 현저하게 높은 캐쉬 위치를 나타내는 스레드의 블록과 함께 제공될 수 있고, 캐쉬 누락의 감소와 시스템 성능의 증가에 이르게 된다.

도18은 본 발명의 실시예에 따라서, 스레드 번들링을 포함하는, 예시적인 2층 스케쥴링 계층구조를 나타낸다. 루트 층으로부터 가장 먼 층인, 차일드 층은 FIFO 스케쥴링 알고리즘을 이용하고 있다. 루트 층 스케쥴러 알고리즘은 라운드 로빈으로써 구성된다. 실시예에서, 각각의 FIFO 큐 내에 있는 엘리먼트들은 동일한 큐의 다른 멤버들과 함께 높은 레벨의 캐쉬 위치를 나타낸다.

도18(a)은 차일드 층 스레드 번들 한도가 1로 설정된 스케쥴링 결과를 보여준다. 결과는 완전히 인터리브(interleave)된다. 이 계획은 각각의 큐에 최소의 레이턴시(latency)를 제공하지만; 이는 최소의 메모리 인식이다(즉, 열악한 캐쉬 성능을 나타낼 가능성이 크다). 콘텍스트 스위치는 각각이 스레드를 스케쥴한 후에 필요하다. 루트 층이 캐쉬를 사용하는 처리 리소스(150)와 연관된다면, 강제적인 캐쉬 누락은 시스템 성능에 충격을 줄 수 있을 것이다.

도18(b)은 차일드 층 스레드 번들 한도가 4로 설정된 스케쥴링 결과를 보여준다. 스케쥴러는 보다 성긴(coarse) 그레인 업데이트 특성을 나타내며, 이는 스레드 번들 한도에 의해 설정된 한도를 갖는 동일한 큐로부터 스케쥴링되고 있는 스레드의 블록으로써 그 자신을 증명한다. 비록 이러한 파열성(bursty) 거동이 일부 환경에서는 이상적이지 않을 수 있지만, 콘텍스트 스위치가 비교적 빈번하게 요구될 때 이는 훨씬 나은 캐쉬 성능을 나타낸다. 결과적인 효과는 성긴 그레인 멀티스레딩의 보다 나은 캐쉬 성능과 필적하는 한편 미세한 그레인 어프로치의 보다 나은 프로그래밍 모델을 유지한다.

시스템이 외부 세계와 상호작용하는 경우 스레드 번들링의 파열 특성은 가장 바람직하지 않을 것 같다. 그러나 스레드 번들링은 타깃 처리 리소스(150)가 캐쉬를 사용하는 경우 유일한 이점이며, 따라서 외부 세계와 상호작용하는 스페셜리스트 처리 리소스(150), 가령 입출력 디바이스는 캐쉬 기술을 사용할 것 같지 않고 따라서 스레드 번들링을 이용하지 않을 것이다.

도17로 돌아가면, 엘리먼트들은 처리 리소스(150)에 의해 제어기(130) API를 통해 호출된 팝 동작을 경유하여 디스패치 큐로부터 제거된다. 엘리먼트는 선취의 경우 준비된 큐로 다시 푸쉬될 수 있다.

우선순위 필드는 우선순위 한도 프로토콜의 실행을 가능하게 하는 디스패치 큐 기술자에 포함되며, 공유된 데이터와의 우선순위 반전을 방지한다. 각각의 처리 리소스(150)는 유일한 디스패치 큐를 가지고 있다.

스케쥴링

애플리케이션 및 시스템을 위한 스케쥴링의 요건은 넓게 변하며, 실은 실제 동작 환경에서의 테스트 후에만 명료해질 수 있다. 이를 조화시키기 위하여, 시스템 관리 제어기(130)는 멀티코어 프로세서 설계 단계를 통해 수정되고 조정될 수 있는 사용된 스케쥴링 방침 및 스케쥴링 알고리즘 모두에 유연성을 전달한다.

스케쥴링 방침은 세 가지 유형으로 분리될 수 있다:

1. 협동 스케쥴러는 새로운 것을 스케쥴링하기 전에 처리 리소스(150)를 방출하기 위하여 현재 실행중인 태스크에 의존한다. 비록 이러한 유형의 시스템은 콜드-캐쉬(cold-cache) 효과의 최소화, 및 고정된 기능의 하드웨어 가속기와는 일관되지만, 보다 복잡한 내장형 애플리케이션에 적절하지 않을 수 있다.

2. 정적 알고리즘으로 구동되는 스케쥴러는 보다 적임의 태스크를 실행하기 위하여 현재 실행중인 태스크를 선취할 수 있다. 미리 정의된 스케쥴링 파라미터 및 알고리즘에 따른, 가장 적임의 스레드는 언제나 이 시스템에서의 실행중인 스레드이다. 임의의 주어진 태스크의 적임성은 시스템이 실행을 시작하기 전에 결정된다.

3. 동적 알고리즘으로 구동되는 스케쥴러는 런타임에 적임성을 재정의할 수 있다. 이전처럼, 현재 실행중인 프로세스는 여전히 가장 높은 적임성을 갖지만, 적임성 메트릭은 태스크가 실행을 개시한 이래로 변경되어 왔을 수 있다.

시스템 관리 제어기(130)는 적절한 구성 및 타깃 애플리케이션과의 런타임 상호작용을 통해서 모든 세 개의 스케쥴링 방침을 만족시킨다.

시스템 관리 제어기(130)는 동작 시스템 및 통신 커뮤니티 모두에서 발견되는 여러 스케쥴링 알고리즘을 지원한다. 예를 들어, 선입선출 큐잉, 우선순위 큐잉 또는 가중된 공정한 큐잉(weighted fair queuing)이 있다. 스케쥴링 알고리즘의 적절한 선택은, 특히 주관적인 품질 메트릭이 포함되는 경우, 예증가능한 이점을 나타낼 것이다.

시스템 관리 제어기(130) 내의 스케쥴링 거동을 지원하기 위하여, 두 개의 스케쥴러 메트릭이 스레드 기술자 내부에 제공된다. 첫 번째는 모든 경우에서의 스레드의 우선순위를 나타내며 계류중인 큐 구조, 우선순위 기반의 스케쥴러 및 디스패치 큐 구조 내부에 사용된다. 필요한 경우, 두 번째는 개별 스레드와 그 피어들 사이에서 선택하기 위하여 사용된다. 또한, 어느쪽의 메트릭이든 페어런트 기술자 내의 메트릭을 업데이트하기 위해 사용될 수 있다. 스레드 기술자의 제2 프리미티브 내부에 놓여진 값은 그 스케쥴러 계층구조에서 마주하는 스케쥴링의 유형을 반영해야 한다.

이러한 두 개의 스케쥴링 메트릭은 스케쥴러 기술자, 및 스레드 기술자 모두에 사용된다. 그러나, 비록 스레드 메트릭이 처리 리소스(150) 내에서 계산되지만, 스케쥴러 층에 대해서는 가능하지 않다. 결과적으로, 스케쥴러 층이 그 자신의 메트릭을 업데이트할 수 있게 하기 위해서는 충분한 파라미터가 주어진 층의 스케쥴링된 스레드로부터 통과되어야 한다. 한 세트의 명령들은 메트릭이 차일드로부터 페어런트로 전달되는 방법을 정의하는 각각의 스케쥴러 층에 대하여 정의된다.

*전체 스케쥴러 계층구조에 대한 약간의 주의를 갖는다면, 복잡한 조합의 스케쥴러 알고리즘이 복잡한 트래픽 및 애플리케이션 시스템 내의 태스크 관리 능력을 제공하기 위해 쉽게 생성될 수 있다.

파라미터 계승 예

도19는 통신 시스템에서 공통적으로 발견될 수 있는 간략화된 큐 구조의 예시적인 실시예이다. 구조는 입출력 디바이스용의 출력 큐를 나타낸다. FIFO 큐를 공유하는 모든 스레드는 동일한 접속상에 있어서, 이는 접속마다의 큐잉 구조이다. 제2의 스케쥴링 층은 이 예에서 가중된 공정한 큐잉(WFQ) 알고리즘을 사용한다. 이 알고리즘은 그 길이 및 가중된 인자에 기초하여 주어진 태스크의 종료 시간을 계산한다. 그 후, 가장 빠른 종료 시간을 갖는 패킷을 선택한다. 비록 WFQ는 스레드가 나타내는 패킷의 길이에 대한 지식을 신뢰하지만, 최초의 FIFO 큐는 이 정보로부터 독립적이다. 이 경우, 애플리케이션 프로그래머는 패킷의 길이가 각 스레드에 대한 스케쥴러 메트릭에 존재하는 것을 보장해야 한다. 계층구조에서의 보다 높은 스케쥴러 층은 그 자신의 스케쥴링 알고리즘에 대해 이 파라미터를 계승한다.

WFQ에 대하여 다음의 변수가 요구된다:

P 접속에 할당된 파이프 대역폭의 분수

l 패킷의 길이

B 전체의 파이프 대역폭

c 접속 대역폭

d 스케쥴러 층 데드라인

접속 대역폭 c를 계산하는 방정식은:

P * B = c

만약 1의 대역폭으로 채널을 정규화한다면, p는 c와 같게 된다. 패킷의 처리의 최종 시간 t는 그 후 다음에 의해 주어진다:

요구되는 메트릭은 그 후 1/p 및 l이다. p는 원래 분수였기 때문에, 이러한 값들 모두(1/p 및 l)는 정수이다. 스케쥴링된 패킷의 길이는 층의 데드라인을 점진적으로 업데이트하면서 스케쥴러 계층구조를 통해 통과된다. 전체적으로, 각 업데이트 내에서 수행된 계산은 다음과 같다:

여기서 d와 1/p(가중치)는 스케쥴러 층 기술자 내에 저장되며, l은 스케쥴 업데이트 동안 계층구조를 통해 통과된다. 이 계산은 스케쥴러 관리자(330) 내에서 수행된다.

본 발명의 특정 실시예가 기재되어 왔지만, 이는 단지 예시적인 방법이며 다양한 수정이 고려될 수 있음이 이해되어야 한다. 게다가, 본 발명은 가령 휴대폰 또는 VoIP(voice over Internet Protocol)를 포함하나 이에 제한되지는 않는 멀티코어 프로세서를 채용하는 임의의 디바이스 또는 애플리케이션에서의 일반적인 애플리케이션에 대한 것이다. 따라서 특정 실시예가 다음 청구항에 의해 결정되어야 할 보호의 범위를 제한하는 것으로 간주하여서는 안 된다.

Claims

프로세싱 실행가능한 트랜잭션에 대해 리소스를 제공하는 다수의 인터커넥트(interconnect)된 프로세서 요소를 구비하는 멀티코어 프로세서에 설치하기 위한 리소스 관리 및 태스크 할당 제어기로서, 상기 요소의 적어도 하나는 마스터 프로세싱 유닛이고;
상기 제어기는, 설치될 때, 마스터 프로세싱 유닛을 포함하는 각각의 프로세서 요소와 통신하도록 적응되며, 미리정의된 할당 파라미터에 따라서 멀티코어 프로세서내의 실행가능한 트랜잭션들을 특정 프로세서 요소들에 할당하는 제어 로직을 포함하는 리소스 관리 및 태스크 할당 제어기.
제1항에 있어서, 상기 제어기의 상기 제어 로직내에 포함되는 상기 미리정의된 할당 매개변수의 범위는, 상기 실행가능한 트랜잭션의 실행의 타이밍 및/또는 순서를 상기 프로세서 요소에 의해 스케쥴링하기 위한 다수의 시스템 관리 규칙을 포함하는 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제1항 또는 제2항에 있어서, 상기 제어기의 상기 제어 로직내에 포함되는 상기 미리정의된 할당 매개변수의 범위는, 상기 실행가능한 트랜잭션이 상기 프로세서 요소에 의해 실행되는 방식을 제어하기 위한 다수의 시스템 관리 규칙을 포함하는 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제2항 또는 제3항에 있어서, 상기 제어기는 상기 프로세싱 유닛과 통신하기 위한 명령을 생성하도록 더 구성되는 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제4항에 있어서, 상기 제어기는 프로세서 요소에 프로세서 요소 구성 명령을 송신하도록 구성되며, 이에 의해 상기 프로세서 요소는 상기 제어기에 의해 상기 프로세서 요소에 할당된 실행가능한 트랜잭션의 이후의 실행을 허용하도록 적응되는 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제4항 또는 제5항에 있어서, 상기 제어기는 상기 프로세서 요소로 하나 이상의 인터럽트의 전송하는 것에 의해 명령을 발생시키도록 구성된 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제4항 또는 제5항에 있어서, 상기 제어기는 상기 프로세서 요소로 하나 이상의 폴(poll)을 전송하는 것에 의해 명령을 발생시키도록 구성된 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
선행하는 청구항들 중 어느 한 항에 있어서, 상기 제어 로직은:
실행가능한 트랜잭션 관리자; 및
전용의 메모리 관리자를 더 포함하며,
상기 전용의 메모리 관리자는 상기 실행가능한 트랜잭션 관리자에 의한 상기 전용 메모리로의 액세스를 제어하는 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제8항에 있어서, 상기 실행가능한 트랜잭션 관리자는 상기 전용 메모리내에 이용가능한 메모리의 표시를 유지하도록 구성된 실행가능한 트랜잭션 입력 관리자를 더 포함하는 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제9항에 있어서, 상기 실행가능한 트랜잭션 관리자 입력은 상기 전용 메모리내에 이용가능한 메모리 할당의 리스트를 유지하도록 구성된 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제10항에 있어서, 상기 실행가능한 트랜잭션 입력 관리자는 상기 전용 메모리 관리자로부터의 업데이트된 명령의 결과로써 이용가능한 메모리의 표시를 유지하는 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
선행하는 청구항들 중 어느 한 항에 있어서, 할당될 상기 실행가능한 트랜잭션은 스레드들을 포함하며 - 스레드 각각은 멀티코어 프로세서에서 실행되고 있는 어플리케이션의 일부를 형성함 -, 상기 스레드들의 적어도 일부는 다른 이벤트와 독립적으로 실행가능한 독립 스레드이며, 상기 스레드들의 적어도 일부는 그 실행이 예정된 이벤트의 존재에 종속하는 종속 스레드인 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제12항에 있어서, 상기 제어 로직은 상기 실행가능한 트랜잭션 관리자에게 타이머 기능을 제공하도록 구성된 시간 관리자를 더 포함하는 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제13항에 있어서, 상기 소정의 이벤트는 타이밍 이벤트인 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제12항에 있어서, 상기 소정의 이벤트는 이전 스레드의 실행의 완결, 또는 다른 보다 적임의 스레드의 선취인 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제12항에 있어서, 상기 실행가능한 트랜잭션 관리자는, 소정의 이벤트의 발생을 기다리는 종속 스레드들을 표시하는 상기 전용의 메모리내의 하나 이상의 계류중인 큐 리스트와, 타이밍 이벤트를 기다리는 스레드들을 표시하는 상기 전용의 메모리내의 하나 이상의 타이머 큐 리스트를 유지하도록 구성된, 실행가능한 트랜잭션 동기화 관리자를 더 포함하는 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제16항에 있어서, 상기 실행가능한 트랜잭션 관리자는, 프로세서 요소들 중 관련된 것에서의 실행을 기다리는 스레드들을 표시하는 상기 전용의 메모리내의 다수의 디스패치 큐 구조를 유지하고, 실행을 위한 프로세서 요소들 중 하나로의 할당을 기다리는 스레드들 표시하는 상기 전용의 메모리내의 다수의 준비된 큐 구조를 유지하도록 구성된, 실행가능한 트랜잭션 출력 관리자를 더 포함하는 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제17항에 있어서, 상기 실행가능한 트랜잭션 관리자는, 각각의 프로세서 요소에 대하여 준비된 큐들 내부로부터 상기 디스패치 큐로 스레드들의 디스패치를 우선순위 매기는 스케쥴링 결정들을 제공 및 유지하도록 구성된, 실행가능한 트랜잭션 스케쥴 관리자를 더 포함하는 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
선행하는 청구항들 중 어느 한 항에 있어서, 상기 제어 논리는, 상기 실행가능한 트랜잭션 관리자와 통신하며 상기 멀티코어 프로세서로 상기 제어기에 의한 액세스를 관리하도록 구성된, 시스템 인터페이스 관리자를 더 포함하는 것을 특징으로 하는 리소스 관리 및 태스크 할당 제어기.
제19항에 있어서, 상기 시스템 인터페이스 관리자는, 상기 실행가능한 트랜잭션 관리자로의 인터커넥트 인터페이싱 및 구성 및 런타임(run-time) 액세스를 제공하도록 배치된 것을 특징으로 하는, 리소스 관리 및 태스크 할당 제어기.
제6항에 있어서, 상기 제어 로직은, 멀티코어 프로세서 내에서 채용된 제1 포맷의 시스템 인터럽트들을, 상기 실행가능한 트랜잭션 관리자에 의해 이해가능한 제2의 상이한 포맷의 제어기 인터럽트들로 변환하기 위한 시스템 인터럽트 관리자를 더 포함하는 것을 특징으로 하는, 리소스 관리 및 태스크 할당 제어기.
선행하는 청구항들 중 어느 한 항의 제어기를 포함하는 멀티코어 프로세서 - 상기 멀티코어 프로세서는 다수의 인터커넥트된 프로세서 요소를 구비하며, 상기 요소 각각은 연관된 제어기 클라이언트를 가짐 - 로서, 각각의 제어기 클라이언트는, 상기 제어기로부터의 제어 신호에 의존하여, 상기 프로세싱 유닛과 상기 멀티코어 프로세서의 나머지 사이의 통신을 제어하도록 구성된 것을 특징으로 하는 멀티코어 프로세서.
선행하는 청구항들 중 어느 한 항의 제어기를 포함하는 멀티코어 프로세서 - 상기 멀티코어 프로세서는 다수의 인터커넥트된 프로세서 요소와 하나 이상의 제어기 클라이언트를 구비함 - 로서, 상기 제어기 클라이언트는, 상기 제어기로부터의 제어 신호에 의존하여, 상기 프로세싱 유닛과 상기 멀티코어 프로세서의 나머지 사이의 통신을 제어하도록 구성된 것을 특징으로 하는 멀티코어 프로세서.
제22항에 있어서, 상기 멀티코어 프로세서는 상기 제어기와 상기 다수의 인터커넥트된 프로세서 요소 모두에 의해 액세스가능한 공유된 시스템 인터커넥트를 더 포함하는 것을 특징으로 하는 멀티코어 프로세서.
제24항에 있어서, 상기 멀티코어 프로세서는 상기 멀티코어 프로세서를 하나 이상의 외부 디바이스로 연결하기 위한 외부 인터페이스를 더 포함하는 것을 특징으로 하는 멀티코어 프로세서.
제22항 내지 제25항에 있어서, 상기 멀티코어 프로세서는 상기 제어기와 통신하는 전용의 메모리를 더 포함하는 것을 특징으로 하는 멀티코어 프로세서.
제26항에 있어서, 상기 전용 메모리는 상기 제어기에 의해서만 배타적으로 액세스가능한 것을 특징으로 하는 멀티코어 프로세서.
제22항에 있어서, 상기 전용 메모리는 상기 제어기와 상기 멀티코어 프로세서의 하나 이상의 추가적인 컴포넌트 모두에 의해 액세스가능한 것을 특징으로 하는 멀티코어 프로세서.
제22항 내지 제27항에 있어서, 상기 메모리는 다수의 개별 메모리 요소를 포함하는 것을 특징으로 하는 멀티코어 프로세서.
제29항에 있어서, 상기 개별 메모리 요소의 수는 유저 정의가능한 것을 특징으로 하는 멀티코어 프로세서.
제30항에 있어서, 각각의 상기 메모리 요소는 유사한 사이즈이며 상기 메모리 요소의 유저 정의가능한 수는 가변 메모리 사이즈로 귀결되는 것을 특징으로 하는 멀티코어 프로세서.
제22항에 있어서, 상기 제어기 클라이언트는 상기 연관된 프로세서 요소에서 실행되는 소프트웨어 어플리케이션인 것을 특징으로 하는 멀티코어 프로세서.
제22항에 있어서, 상기 제어기 클라이언트는 상기 연관된 프로세서 요소의 기능성에 의존하는 하드웨어 제어기 클라이언트인 것을 특징으로 하는 멀티코어 프로세서.
제33항에 있어서, 상기 제어기 클라이언트는 상기 제어기로부터의 제어 신호에 의해 활성화될 때 상기 연관된 프로세서 요소를 제어하기 위한 클라이언트 제어 로직을 더 포함하는 것을 특징으로 하는 멀티코어 프로세서.
제34항에 있어서, 상기 제어기 클라이언트는 상기 프로세서 요소와 상기 멀티코어 프로세서의 나머지 사이에서 송신되는 통신 메시지의 임시 저장을 위한 다수의 버퍼를 더 포함하는 것을 특징으로 하는 멀티코어 프로세서.
제35항에 있어서, 상기 다수의 버퍼는 선입선출 버퍼인 것을 특징으로 하는 멀티코어 프로세서.
제35항에 있어서, 상기 제어기 클라이언트는, 각 메모리 요소가 어드레스를 저장하도록 구성된 다수의 메모리 요소를 더 포함하는 것을 특징으로 하는 멀티코어 프로세서.
제37항에 있어서, 상기 제어기 클라이언트는, 각 비교기가 상기 연관된 프로세서 요소에 의해 생성된 어드레스를 상기 메모리 요소 중 하나에 저장된 어드레스와 비교하도록 구성된 다수의 비교기를 더 포함하는 것을 특징으로 하는 멀티코어 프로세서.
제37항에 있어서, 상기 제어기 클라이언트는, 상기 연관된 프로세서 요소에 의해 생성된 어드레스로부터 상기 메모리 요소들 중 하나에 저장된 어드레스를 빼도록 구성된 차분기를 더 포함하는 것을 특징으로 하는 멀티코어 프로세서.
요소의 하나 이상은 마스터 프로세싱 유닛인 다수의 프로세서 요소를 구비하는 멀티코어 프로세서 내에서 리소스를 제어하고 할당하는 방법으로서;
상기 마스터 프로세서 유닛과는 별도의 리소스 관리 및 태스크 할당 제어기에서 실행가능한 트랜잭션을 수신하는 단계;
상기 실행가능한 트랜잭션을 중앙 처리 유닛 제어와는 독립적으로 상기 프로세서 요소 중 하나에 할당하는 단계를 포함하는 리소스 제어 및 할당 방법.
제40항에 있어서, 트랜잭션 관리 클라이언트를 경유하여 상기 프로세서 요소 중 하나로 상기 실행가능한 트랜잭션을 보내는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제41항에 있어서, 상기 트랜잭션 관리 클라이언트는 하드웨어 클라이언트인 것을 특징으로 하는 리소스 제어 및 할당 방법.
제41항에 있어서, 상기 트랜잭션 관리 클라이언트는 소프트웨어 클라이언트인 것을 특징으로 하는 리소스 제어 및 할당 방법.
제42항에 있어서, 상기 트랜잭션 관리 클라이언트 내부에 미리결정된 어드레스를 저장하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제44항에 있어서,
상기 트랜잭션 관리 클라이언트에서, 정규화된 어드레스를 생성하기 위하여 상기 연관된 프로세싱 요소에 의해 생성된 어드레스로부터 상기 미리결정된 어드레스를 빼는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제44항에 있어서,
상기 트랜잭션 관리 클라이언트에서, 상기 연관된 프로세서 요소에 의해 생성된 어드레스를 상기 저장된 미리결정된 어드레스와 비교하는 단계; 및
상기 비교의 결과에 의존하여 상기 프로세서 요소를 구성하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제42항에 있어서,
상기 트랜잭션 관리 클라이언트에서, 상기 멀티코어 프로세서의 나머지로부터 상기 연관된 프로세서 요소로의 통신 메시지의 전체를 저장하는 단계; 및
상기 연관된 프로세서 요소로 상기 전체 메시지를 통과시키는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제42항에 있어서,
상기 트랜잭션 관리 클라이언트에서, 상기 멀티코어 프로세서의 나머지로부터 상기 연관된 프로세서 요소로 통신 메시지를 스트리밍하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제41항에 있어서, 제1 트랜잭션 관리 클라이언트에 대한 실행가능한 트랜잭션을 제2 트랜잭션 관리 클라이언트로 생성하거나, 실행하거나, 또는 삭제하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제40항 내지 제49항 중 어느 한 항에 있어서, 미리정의된 스케쥴링 파라미터쌍에 기초하여 상기 실행가능한 트랜잭션을 상기 프로세싱 요소들 중 하나에 할당하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제50항에 있어서, 상기 스케쥴링 파라미터 쌍은 유저 정의가능한 것을 특징으로 하는 리소스 제어 및 할당 방법.
제50항 또는 제51항에 있어서, 상기 제어기에 의해 사용하기 위한 스케쥴링 파라미터의 리스트를 모니터링하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제50항 내지 제52항 중 어느 한 항에 있어서, 상기 스케쥴링 파라미터쌍을 시간에 따라 변화시키는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제52항에 있어서, 상기 스케쥴링 파라미터의 리스트를 유지하는 단계는 하나 이상의 상기 프로세서 요소에 의해 실행될 수 있는 준비된 태스크들의 리스트를 유지하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제50항 내지 제53항 중 어느 한 항에 있어서, 상기 멀티코어 프로세서 내의 프로세서 리소스들을 균형맞추기 위한 요건에 기초하여 상기 실행가능한 트랜잭션을 상기 프로세싱 요소 중 하나에 할당하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제50항 내지 제53항 중 어느 한 항에 있어서, 상기 프로세서 요소가 보다 높은 우선권 태스크를 실행하는 것이 바람직하다고 결정될 때, 상기 실행가능한 트랜잭션이 상기 프로세서 요소 중 하나로 할당되는 것을 방지하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제40항 내지 제56항 중 어느 한 항에 있어서, 미리결정된 시간 길이보다 긴 시간 동안 할당되지 않았던 실행가능한 트랜잭션의 리스트를 유지하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제52항에 있어서, 상기 스케쥴링 파라미터의 리스트를 모니터링하는 단계는 미리결정된 이벤트를 기다리고 있는 계류중인 태스크의 리스트를 유지하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제58에 있어서, 상기 미리결정된 이벤트는 타이머 이벤트거나, 동기화 이벤트거나, 또는 둘 모두인 것을 특징으로 하는 리소스 제어 및 할당 방법.
제58항에 있어서, 상호 배타적인 미리결정된 이벤트에 따라서 계류중인 태스크들의 다수의 리스트를 유지하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제52항에 있어서, 상기 스케쥴링 파라미터의 리스트를 모니터링하는 단계는 특정 프로세싱 리소스에 대한 실행을 기다리고 있는 디스패치된 태스크들의 리스트를 유지하는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제61항에 있어서, 미리결정된 이벤트를 기다리고 있는 실행가능한 트랜잭션을 타임아웃의 만료시에 준비된 큐로 이동시키는 단계를 더 포함하는 것을 특징으로 하는 리소스 제어 및 할당 방법.
제40항 내지 제62항 중 어느 한 항에 있어서, 상기 제어기는 태스크들의 할당에 배타적으로 전용화되는 것을 특징으로 하는 리소스 제어 및 할당 방법.
첨부된 도면을 참조하여 본원에 실질적으로 기재된 멀티코어 프로세서용 리소스 관리 및 태스크 할당 제어기.
첨부된 도면을 참조하여 본원에 실질적으로 기재된 멀티코어 프로세서.
첨부된 도면을 참조하여 본원에 실질적으로 기재된 멀티코어 프로세서에서 리소스를 제어하고 할당하는 방법.