KR20140127341A - 휴대용 컴퓨팅 디바이스에서 요청들을 스케쥴링하기 위한 방법 및 시스템 - Google Patents

휴대용 컴퓨팅 디바이스에서 요청들을 스케쥴링하기 위한 방법 및 시스템 Download PDF

Info

Publication number
KR20140127341A
KR20140127341A KR1020147026292A KR20147026292A KR20140127341A KR 20140127341 A KR20140127341 A KR 20140127341A KR 1020147026292 A KR1020147026292 A KR 1020147026292A KR 20147026292 A KR20147026292 A KR 20147026292A KR 20140127341 A KR20140127341 A KR 20140127341A
Authority
KR
South Korea
Prior art keywords
request
requests
resource
processor
resources
Prior art date
Application number
KR1020147026292A
Other languages
English (en)
Other versions
KR101551321B1 (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 KR20140127341A publication Critical patent/KR20140127341A/ko
Application granted granted Critical
Publication of KR101551321B1 publication Critical patent/KR101551321B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/329—Power saving characterised by the action undertaken by task scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4893—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues taking into account power or heat criteria
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0216—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave using a pre-established activity schedule, e.g. traffic indication frame
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0261—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level
    • H04W52/0274—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof
    • H04W52/0277—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof according to available power supply, e.g. switching off when a low battery condition is detected
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Sources (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Multi Processors (AREA)

Abstract

휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법 및 시스템은 복수의 요청들을 스케쥴링하기 위한 클라이언트로부터의 데이터를 수신하는 스케쥴러를 포함한다. 각각의 요청은 적어도 하나의 리소스 및 요청된 데드라인을 식별한다. 다음으로, 클라이언트로부터의 데이터는 데이터베이스 내의 스케쥴러에 의해 저장된다. 스케쥴러는 이후 요청들에서의 요청된 데드라인들에 기초하여 그리고 휴대용 컴퓨팅 디바이스 내의 리소스들의 현재 상태에 기초하여 요청들을 프로세싱하기 위한 시간들 및 시퀀스를 결정한다. 스케쥴러는 이후 결정된 시간들에서 그리고 결정된 시퀀스에 따라 리소스들에 대한 요청들을 통신한다. 스케쥴러는, 임의로, 클라이언트로부터 새로운 요청 커맨드를 수신하는 것에 응답하여 요청된 데드라인 이후에 요청을 스케쥴링할 수 있다. 스케쥴러는 슬립 프로세서 상태에 대응하는 슬립 세트가 프로세서의 전원을 차단하게 하도록 할 수 있다.

Description

휴대용 컴퓨팅 디바이스에서 요청들을 스케쥴링하기 위한 방법 및 시스템{METHOD AND SYSTEM FOR SCHEDULING REQUESTS IN A PORTABLE COMPUTING DEVICE}
이 출원은 35 U.S.C.§119(e)조항 하에서, "METHOD AND SYSTEM FOR SCHEDULING REQUESTS IN A PORTABLE COMPUTING DEVICE"라는 명칭으로 2012년 2월 23일에 출원된 미국 가특허 출원 번호 제61/602,287호를 우선권으로 주장한다. 그로 인해서 그 가특허 출원의 전체 내용은 본원에 인용에 의해 통합된다.
PCD(Portable computing device)들은 점점 더 인기가 높아지고 있다. 이들 디바이스들은 셀룰러 전화들, PDA(portable/personal digital assistant)들, 휴대용 게임 콘솔들, 휴대용 내비게이션 유닛들, 팜톱 컴퓨터들 및 다른 휴대용 전자 디바이스들을 포함할 수 있다. 이들 디바이스들 각각은 주요(primary) 기능을 가질 수 있다. 셀룰러 전화는 일반적으로 전화 호출들을 수신하고 발신하는 주요 기능을 가진다.
이들 디바이스들의 주요 기능에 더하여, 다수가 주변 기능들을 포함한다. 예를 들어, 셀룰러 전화는 전술된 바와 같이 셀룰러 전화 호출을 거는 주요 기능, 및 스틸 카메라, 비디오 카메라, GPS(global positioning system) 내비게이션, 웹 브라우징, e-메일들의 송신과 수신, 텍스트 메시지들의 송신과 수신 및 푸시-투-토크(push-to-talk) 능력들 등의 주변 기능들을 포함할 수 있다. PCD들의 기능성이 증가함에 따라, 이러한 기능성을 지원하기 위해 요구되는 컴퓨팅 또는 프로세싱 전력이 또한 증가한다. 프로세싱 전력은 PCD 내의 프로세서들의 수를 증가시킴으로써 증가할 수 있다. 프로세서들의 컴퓨팅 전력과 수가 증가함에 따라, 프로세서들을 효과적으로 관리하기 위한 더 큰 필요성이 존재한다.
전술된 것과 같은 기능들은 리소스들이라고 지칭될 수 있는 다양한 대응하는 하드웨어 및 소프트웨어 엘리먼트들에서 구현될 수 있다. 프로세서는 응용 프로그램과 같은 소프트웨어의 제어하에 여러번 다양한 리소스들을 요청할 수 있다. 멀티-프로세서 PCD에서, 제1 프로세서는 제2 프로세서에 의해 제어되는 리소스들과는 상이한 리소스들을 제어할 수 있다. 종래 기술에서, 프로세서들에 걸쳐 효율적으로 리소스들을 관리하는 것은 이들 리소스들에 의해 소모되는 전력을 보존하기에 매우 복잡하고 어려울 수 있다.
휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법 및 시스템이 개시된다. 방법 및 시스템은 복수의 요청들을 스케쥴링하기 위한 클라이언트로부터의 데이터를 수신하는 스케쥴러를 포함한다. 각각의 요청은 적어도 하나의 리소스 및 요청된 데드라인을 식별한다. 다음으로, 클라이언트로부터의 데이터는 스케쥴러에 의해 데이터베이스에 저장된다. 스케쥴러는 이후, 요청들에서의 요청된 데드라인들에 기초하여 그리고 휴대용 컴퓨팅 디바이스 내의 리소스들의 현재 상태들에 기초하여 요청들을 프로세싱하기 위한 시간들 및 시퀀스를 결정한다. 스케줄러는 이후 결정된 시간들에서 그리고 결정된 시퀀스에 따라 리소스들에 대한 요청들을 통신한다.
스케쥴러는, 임의로, 클라이언트로부터 새로운 요청 커맨드를 수신하는 것에 응답하여 요청된 데드라인 이후에 요청을 스케쥴링할 수 있다. 스케쥴러는 슬립 프로세서 상태에 대응하는 슬립 세트가 프로세서의 전원을 차단하게 하도록 할 수 있고, 따라서 프로세서가 슬립 프로세서 상태를 이탈할 때 프로세서는 하나 이상의 스케쥴링된 요청들에 대한 작용을 계속할 수 있다. 스케쥴러가 스케쥴링된 슬립 상태 동안 예상되지 않은 요청을 수신하는 경우, 스케쥴러는 하나 이상의 스케쥴링된 요청들이 예상되지 않은 요청에 응답할 필요가 있는지를 결정할 수 있다. 하나 이상의 스케쥴링된 요청들이 스케쥴링된 슬립 상태 동안 예상되지 않은 요청에 응답할 필요가 없는 경우, 스케쥴러는 하나 이상의 스케쥴링된 요청들을 취소하고, 이후 취소된 스케쥴링된 요청들 중 하나 이상을 다음 스케쥴링된 활성 상태에서 발생하도록 재스케쥴링할 수 있다.
도면들에서, 동일한 참조 번호들은 다른 방식으로 지시되지 않는 한 다양한 뷰들 전반에 걸쳐 동일한 부분들을 지칭한다. "102A" 또는 "102B"와 같은 문자 캐릭터 표기를 가지는 참조 번호들에 대해, 문자 캐릭터 표기들은 동일한 도면에 존재하는 2개의 동일한 부분들 또는 엘리먼트들을 차별화할 수 있다. 참조 번호들에 대한 문자 캐릭터 표기들은, 참조 번호가 모든 도면들에서 동일한 참조 번호를 가지는 모든 부분들을 포함하도록 의도될 때 생략될 수 있다.
도 1은 PCD(portable computing device) 내의 분배된 리소스 관리를 위한 시스템의 예시적인 엘리먼트들을 예시하는 기능 블록도이다.
도 2는 제1 프로세서가 제2 프로세서에 의해 제어되는 리소스를 요청할 필요가 있는 경우의 예를 예시하는 기능 블록도이다.
도 3은 PCD의 리소스들을 관리하는 노드 아키텍쳐의 제1 양상의 다이어그램이다.
도 4는 PCD의 예시적인 리소스들의 그룹에 대한 방향성 비순환 리소스 그래프(directed acyclic resource graph)이다.
도 5는 PCD의 리소스들을 관리하는 노드 아키텍쳐의 제2 양상의 일반적인 다이어그램이다.
도 6은 PCD의 리소스들을 관리하는 노드 아키텍쳐의 제2 양상의 특정 다이어그램이다.
도 7은 PCD의 리소스들을 관리하기 위한 노드 아키텍쳐를 생성하기 위한 방법을 예시하는 흐름도이다.
도 8은 PCD의 리소스들을 관리하기 위한 노드 아키텍쳐를 생성하기 위한 방법을 예시하는 도 7의 계속 흐름도이다.
도 9는 PCD에 대한 소프트웨어 아키텍쳐에서 노드 구조 데이터를 수신하기 위한 도 7-8의 서브-방법 또는 루틴을 예시하는 흐름도이다.
도 10은 PCD에 대한 소프트웨어 아키텍쳐에서 노드를 생성하기 위한 도 7-8의 서브-방법 또는 루틴을 예시하는 흐름도이다.
도 11은 PCD의 소프트웨어 아키텍쳐에서 클라이언트를 생성하기 위한 도 10의 서브-방법 또는 루틴을 예시하는 흐름도이다.
도 12는 PCD에 대한 소프트웨어 아키텍쳐에서 리소스에 대한 클라이언트 요청을 생성하기 위한 방법을 예시하는 흐름도이다.
도 13은 각각이 자신의 고유한 리소스 그래프의 리소스들을 제어하는, 2개의 프로세서들 간의 통신 경로를 예시한다.
도 14는 제어기, 리소스 전력 매니저, 마스터 프로세서들, 로우-레벨 드라이버들, 공유된 리소스들, 및 로컬 리소스들 간의 관계들을 예시하는 기능 블록도이다.
도 15는 제어기 및 트리거 세트들에 관한 상세항목들을 예시하는 기능 블록도이다.
도 16은 프로세서에 대한 예시적인 활성-슬립 트리거 세트를 예시한다.
도 17은 트리거 세트들을 관리하고 어웨이크 상태와 같은 제1 애플리케이션 상태로부터 슬립 상태와 같은 제2 애플리케이션 상태로 프로세서를 다른 방식으로 트랜지션하기 위한 방법을 예시하는 논리적 흐름도이다.
도 18은 트리거 세트들을 관리하고 슬립 상태와 같은 제2 애플리케이션 상태로부터 어웨이크 상태와 같은 제3 애플리케이션 상태로 프로세서를 다른 방식으로 트랜지션하기 위한 방법을 예시하는 논리적 흐름도이다.
도 19는 제어기 버퍼 메모리의 기능 블록도이다.
도 20은 어웨이크 상태와 같은 제1 애플리케이션 상태로부터 슬립 상태와 같은 제2 애플리케이션 상태로 프로세서를 트랜지션하기 위한 대안적인 방법을 예시하는 논리적 흐름도이다.
도 21은 노드 스케쥴러, 스케쥴러 데이터베이스와, 리소스 전력 매니저와 다른 노드 아키텍쳐 시스템 엘리먼트들 간의 관계들을 예시하는 기능 블록도이다.
도 22는 스케쥴러 데이터베이스의 예시적인 콘텐츠를 예시하는 다이어그램이다.
도 23은 클라이언트들, 클라이언트 요청들, 스케쥴러와 타이머 간의 관계들을 보여주는 예시적인 타이밍도를 예시한다.
도 24는 클라이언트들, 클라이언트 요청들, 스케쥴러와 타이머와, 슬립 세트들을 트래킹하는 제어기 간의 관계들을 보여주는 예시적인 타이밍도를 예시한다.
도 25는 하나 이상의 사용자 스레드들(2301)이 스케쥴러(2101)를 호출함으로써 블록(1205A, 1205B)에서 2개의 요청들(675)을 생성할 때 예시적인 타이밍도를 예시한다.
도 26은 클라이언트를 통한 사용자 스레드가, 클라이언트가 더 이상 프로세싱된 특정한 요청을 이용하여 스케쥴링되지 않은 요청 커맨드를 발행하기를 원하지 않는다고 결정할 수 있을 때의 예시적인 타이밍도를 예시한다.
도 27은 요청이 스케쥴링되고 사용자 스레드가 요청을 발행하지만, 스케쥴링되지 않은 요청 커맨드가 발행될 때 스케쥴러가 요청을 프로세싱하기 시작하지 않는 예시적인 타이밍도를 예시한다.
도 28은 요청이 스케쥴링되고 스케쥴러 스레드(2301)가 요청을 발행하며 스케쥴링되지 않은 요청 커맨드가 발행될 때 스케쥴러(2101)가 요청을 프로세싱하기 시작한 예시적인 타이밍도를 예시한다.
도 29는 단일 응용 프로그램이 실행중이며, 활성 상태 동안 하나 이상의 요청들을 프로세싱한 이후, CPU가 스케쥴러가 새로운 요청 기능/특징을 사용하는 슬립 상태에 진입할 수 있는 단순한 시나리오를 예시한다.
도 30은 스케쥴러가 스케쥴링된 슬립 상태 동안 예상되지 않은 웨이크-업들 또는 인터럽트들을 어떻게 관리하는지에 대한 예시적인 시나리오를 예시한다.
단어 "예시적인"은 "예, 경우, 또는 예시로서의 역할을 하는 것"을 의미하도록 본원에서 사용된다. 본원에서 "예시적인" 것으로서 설명된 임의의 양상은 반드시 다른 양상들보다 선호되거나 유리한 것으로서 해석되지는 않아야 한다.
이 설명에서, 용어 "애플리케이션"은 또한: 오브젝트 코드, 스크립트들, 바이트 코드, 마크업 언어 파일들, 및 패치(patch)들과 같은 실행가능한 콘텐츠를 가지는 파일들을 포함할 수 있다. 추가로, 본원에서 지칭되는 "애플리케이션"은 또한 열릴 필요가 있을 수 있는 문서들 또는 액세스될 필요가 있는 다른 데이터 파일과 같은, 속성상 실행가능하지 않는 파일들을 포함할 수 있다.
용어 "콘텐츠"는 또한: 오브젝트 코드, 스크립트들, 바이트 코드, 마크업 언어 파일들, 및 패치들과 같은 실행가능한 콘텐츠를 가지는 파일들을 포함할 수 있다. 추가로, 본원에서 지칭된 "콘텐츠"는 또한 열릴 필요가 있을 수 있는 문서들 또는 액세스될 필요가 있는 다른 데이터 파일들과 같은, 속성상 실행가능하지 않은 파일들을 포함할 수 있다.
이 설명에서 사용되는 바와 같이, 용어들 "컴포넌트", "데이터베이스", "모듈", "시스템" 등은 컴퓨터-관련된 엔티티, 하드웨어, 펌웨어, 하드웨어와 소프트웨어의 결합, 소프트웨어, 또는 실행 중인 소프트웨어 어느 것이라도 지칭하도록 의도된다. 예를 들어, 컴포넌트는 프로세서 상에서 실행 중인 프로세스, 프로세서, 오브젝트, 실행성, 실행 스레드, 프로그램, 및/또는 컴퓨터일 수 있지만, 이에 제한되지는 않는다. 예시에 의해, 컴퓨팅 디바이스 상에서 실행중인 애플리케이션과 컴퓨팅 디바이스 모두가 컴포넌트일 수 있다. 하나 이상의 컴포넌트들은 프로세스 및/또는 실행 스레드 내에 상주할 수 있고, 컴포넌트는 하나의 컴퓨터 상에서 로컬라이즈(localize)될 수 있고 그리고/또는 둘 이상의 컴퓨터들 사이에서 분배될 수 있다. 추가로, 이들 컴포넌트들은 저장된 다양한 데이터 구조들을 가지는 다양한 컴퓨터 판독가능한 매체로부터 실행될 수 있다. 컴포넌트들은 예를 들어, 하나 이상의 데이터 패킷들을 가지는 신호(예를 들어, 로컬 시스템, 분산된 시스템 내의 또다른 컴포넌트와, 그리고/또는 인터넷과 같은 네트워크를 통해 신호에 의해 다른 시스템들과 상호작용하는 하나의 컴포넌트로부터의 데이터)에 따라 로컬 및/또는 원격 프로세스들에 의해 통신할 수 있다.
이 설명에서, 용어들 "통신 디바이스", "무선 디바이스", "무선 전화", "무선 통신 디바이스", 및 "무선 핸드셋"은 상호교환가능하게 사용된다. 제3 세대("3G") 및 제4 세대("4G") 무선 기술의 출현으로, 더 큰 대역폭 이용가능성은 더 많은 휴대용 컴퓨팅 디바이스들이 더욱 다양한 무선 기능들을 가질 수 있게 한다.
이 설명에서, 용어 "PCD(portable computing device)"는 배터리와 같은 제한된 용량의 전원으로 동작하는 임의의 디바이스를 설명하기 위해 사용된다. 배터리 동작 PCD들이 수십 년간 사용되어 왔지만, 제3 세대("3G") 및 제4 세대("4G") 무선 기술의 출현과 관련된 재충전가능한 배터리에서의 기술적 진보는 다수의 PCD들이 다수의 능력들을 가질 수 있게 하였다. 따라서, PCD는, 특히, 셀룰러 전화, 위성 전화, 페이저, PDA(personal digital assistant), 스마트폰, 내비게이션 디바이스, 스마트북 또는 판독기, 미디어 플레이어, 전술된 디바이스들의 결합, 및 무선 접속을 가지는 랩톱 컴퓨터일 수 있다.
도 1은 휴대용 컴퓨팅 디바이스에서 분배된 리소스 관리를 위한 방법들 및 시스템들을 구현하기 위해 무선 전화의 형태인 PCD(100)의 예시적인, 비-제한적인 양상의 기능 블록도이다. 도시된 바와 같이, PCD(100)는 멀티-코어, 중앙 처리 장치("CPU"), 그래픽 프로세서(110B), 및 아날로그 신호 프로세서(126)를 가지는 온-칩 시스템(102)을 포함한다. 이들 프로세서들(110A, 110B, 126)은 당업자에게 공지된 바와 같이, 하나 이상의 시스템 버스들 또는 또다른 상호접속 아키텍쳐 상에서 함께 커플링될 수 있다.
당업자에 의해 이해되는 바와 같이, CPU(110A)는 제0 코어(222), 제1 코어(224) 등 내지 제N 코어를 포함할 수 있다. 대안적인 실시예들에서, CPU(110A)와 그래픽 프로세서(110B) 대신, 하나 이상의 DSP(digital signal processor)들이 또한 당업자에 의해 이해되는 바와 같이 사용될 수 있다. 또한, 대안적인 실시예들에서, 둘 이상의 멀티-코어 프로세서들이 포함될 수 있다.
도 1에 예시된 바와 같이, 디스플레이 제어기(128) 및 터치스크린 제어기(130)가 멀티-코어 CPU(110A)에 커플링된다. 온-칩 시스템(102)에 대해 외부에 있는 터치스크린 디스플레이(132)는 디스플레이 제어기(128) 및 터치스크린 제어기(130)에 커플링된다. 또한, 비디오 코더/디코더("코덱")(134), 예를 들어, PAL(phase-alternating line) 인코더, SECAM(sequential couleur avec memoire) 인코더, NTSC(national television system(s) committee) 인코더, 또는 멀티-코어 CPU(central processing unit)(110A)에 커플링된 다른 타입의 비디오 인코더(134)가 PCD(100)에 포함된다. 비디오 증폭기(136)는 비디오 인코더(134) 및 터치스크린 디스플레이(132)에 커플링된다. 비디오 포트(138)는 비디오 증폭기(136)에 커플링된다. 도 2에 도시된 바와 같이, USB(universal serial bus) 제어기(140)는 CPU(110A)에 커플링된다. 또한, USB 포트(142)는 USB 제어기(140)에 커플링된다. SIM(subscriber identity module) 카드(146)가 또한 CPU(110A)에 커플링될 수 있다. 또한, 도 1에 도시된 바와 같이, 디지털 카메라(148)는 CPU(110A)에 커플링될 수 있다. 예시적인 양상에서, 디지털 카메라(148)는 CCD(charge-coupled device) 카메라 또는 CMOS(complementary metal-oxide semiconductor) 카메라이다.
도 1에 추가로 예시된 바와 같이, 스테레오 오디오 코덱(150)은 아날로그 신호 프로세서(126)에 커플링될 수 있다. 또한, 오디오 증폭기(152)는 스테레오 오디오 코덱(150)에 커플링될 수 있다. 예시적인 양상에서, 제1 스테레오 스피커(154) 및 제2 스테레오 스피커(156)는 오디오 증폭기(152)에 커플링된다. 도 1은 마이크로폰 증폭기(158)가 또한 스테레오 오디오 코덱(150)에 커플링될 수 있음을 도시한다. 추가로, 마이크로폰(160)은 마이크로폰 증폭기(158)에 커플링될 수 있다. 특정 양상에서, FM(frequency modulation) 라디오 튜너(162)는 스테레오 오디오 코덱(150)에 커플링될 수 있다. 또한, FM 안테나(164)는 FM 라디오 튜너(162)에 커플링된다. 또한, 스테레오 헤드폰들(166)은 스테레오 오디오 코덱(150)에 커플링될 수 있다.
도 1은 추가로 RF(radio frequency) 트랜시버(168)가 아날로그 신호 프로세서(126)에 커플링될 수 있음을 나타낸다. RF 스위치(170)는 RF 트랜시버(168)와 RF 안테나(172)에 커플링될 수 있다. 도 1에 도시된 바와 같이, 키패드(174)는 아날로그 신호 프로세서(126)에 커플링될 수 있다. 또한, 마이크로폰이 있는 모노 헤드셋(176)은 아날로그 신호 프로세서(126)에 커플링될 수 있다. 또한, 진동기 디바이스(178)는 아날로그 신호 프로세서(126)에 커플링될 수 있다. 도 1은 또한, 전원(180), 예를 들어, 배터리가 온-칩 시스템(102)에 커플링됨을 보여준다. 특정 양상에서, 전원(180)은 AC 전원에 접속된 AC(alternating current) 대 DC(direct current) 변환기로부터 유도된 DC 전원 또는 재충전가능한 배터리를 포함한다.
PCD(100)의 전술된 엘리먼트들 중 일부는 하드웨어를 포함할 수 있는 반면, 다른 것들은 소프트웨어를 포함할 수 있고, 또다른 것들은 하드웨어와 소프트웨어의 결합을 포함할 수 있다. 용어 "리소스"는 본원에서 프로세서에 의해 제어가능한, 하드웨어, 소프트웨어 또는 하드웨어와 소프트웨어의 결합인, 임의의 이러한 엘리먼트를 지칭하기 위해 본원에서 사용된다. 리소스는 이러한 엘리먼트의 기능성의 캡슐화로서 일 양상에서 정의될 수 있다. 다른 방식으로 표시될 수 있는 경우를 제외하고, 용어 "프로세서" 또는 "마스터 프로세서"는 CPU(110), 그래픽 프로세서(110B), 아날로그 신호 프로세서(126)와 같은 프로세서를 지칭하거나, 또는 임의의 다른 프로세서, 제어기 또는 소프트웨어의 제어 하에서 동작하는 유사한 엘리먼트, 펌웨어, 또는 유사한 제어 로직을 지칭하도록 본원에서 사용된다.
하기에 더 상세하게 기술되어 있는 바와 같이, 리소스의 예는 프로세서 상에서 실행중인 소프트웨어 엘리먼트이다. 예를 들어, 실행하는 응용 프로그램에 관련된 스레드와 같은, 프로세서 상의 실행 스레드는 "요청"이 리소스 상에서 발행되게 함으로써 리소스에 액세스할 수 있다. 하기에 설명되는 바와 같이, 리소스 요청들은 "프레임워크"로서 이 개시내용에서 지칭되는 소프트웨어-기반 시스템을 통해 프로세싱된다.
용어 "클라이언트"는 리소스를 요청하는 기능을 실행하는 엘리먼트를 지칭하도록 이 개시내용에서 널리 사용된다. 따라서, 용어들이 본원에서 사용되는 바와 같이, 스레드는 리소스 요청들을 발행할 목적으로 클라이언트를 생성하거나 사용할 수 있다. 일부 경우들에서, 리소스가 클라이언트를 생성하거나 사용할 수 있고, 따라서, 리소스가 리소스 요청이 또다른 리소스에 대해 발행되게 할 수 있다는 점에 유의해야 한다. 하기에 더 상세하기 기술되는 바와 같이, 이러한 다른 리소스는 요청하는 리소스와 요청된 리소스 간의 종속성 관계로 인해 "종속적인" 리소스로서 본원에서 지칭될 수 있다. 리소스들 및 클라이언트들은 메모리에서 데이터 구조들에 의해 표현될 수 있다.
리소스들이 멀티-프로세서 PCD(100) 내의 특정 프로세서들에 의해 제어되기 때문에, PCD(100) 내의 모든 프로세서가 PCD(100) 내의 모든 리소스에 대한 액세스를 가지지는 않는다. 도 2는 PCD(100) 내의 제1 프로세서(202)가 PCD(100) 내의 제2 프로세서(206)에 의해 제어되는 리소스 전력 매니저(157)에 대해 리소스 요청(203)을 발행하는 것이 바람직할 수 있는 경우의 예를 예시한다. 제1 프로세서(202)가 또한 복수의 리소스들(105A1, 105A2)을 제어할 수 있다는 점에 유의한다. 마찬가지로, 제2 프로세서(206)는 복수의 추가적인 리소스들(105B1, 105B2)을 제어할 수 있다.
제1 프로세서(202)가, 예를 들어, 비디오 플레이어 애플리케이션 프로그램에 관련된 스레드(208)를 실행하는 경우, 스레드(208)는 제1 프로세서(202)의 성능을 향상시키는 제1 프로세서(202)의 하나 이상의 동작 파라미터들의 조정을 요청할 수 있다.(스레드(208) 및 리소스 전력 매니저(157)가 명료함의 목적으로 자신의 각자의 프로세서들(202) 및 206)에 상주하는 것으로서 개념적으로 예시되어 있지만, 당업자는 이러한 엘리먼트들이 잘 이해되는 컴퓨팅 원리들에 따라 프로세서의 메모리 공간에서 프로세서에 의해 실행되거나 다른 방식으로 동작함을 이해한다.) 이러한 동작 파라미터들은, 예를 들어, 클록 속도 및 버스 속도를 포함할 수 있다.
예를 들어, 다양한 프로세서들은 동일한 버스 클록을 사용할 수 있지만, 프로세서들 중 오직 하나만이 버스 클록의 직접적인(하드웨어-레벨) 제어를 가질 수 있다. 클록 속도를 증가시키는 것은, 예를 들어, 비디오 플레이어 애플리케이션 프로그램에 의해 더 양호한 성능을 초래할 수 있는데, 왜냐하면 비디오의 재생이 일반적으로 일부 다른 작업들보다 더 많은 프로세싱 전력-집약적 작업이기 때문이다. 프로세싱 전력이 일반적으로 MIPS(millions of instructions per second)로 표현됨에 따라, 스레드(208)는 특정 수의 MIPS에 대한 호출을 발행할 수 있다. 리소스 전력 매니저(157)는, 특정된 수의 MIPS에 대한 요청에 응답하여, 클록 속도, 버스 속도 또는 요청된 MIPS 레벨에서 동작하도록 제1 프로세서(202)를 조장하는 다른 파라미터들을 나타낼 수 있는 신호들(210)에서의 변경들을 야기하는 알고리즘을 포함할 수 있다.
제1 프로세서(202)가 제2 프로세서(206)와 통신할 수 있는 버스 또는 프로토콜에 대해 특정적인 API(application program interface)를 통해 스레드가 리소스 전력 매니저(157)에 액세스하는 것이 가능할 수 있다. 그러나, 하기에 설명된 프레임워크는 리소스 특정적 및 버스-특정적 API보다 리소스 요청들을 핸들링하기 위한 더욱 균일한 방식을 제공할 수 있다. 하기에 설명된 바와 같이, 프레임워크를 통해, 리소스 요청들은 요청이 동일한 프로세서에 의해 제어되는 리소스에 대한 것인지 또는 상이한 프로세서에 의해 제어되는 리소스에 대한 것인지의 여부와는 무관하게 균일한 방식으로 발행되고 서비스된다. 리소스 요청을 발행한 동일한 프로세서에 의해 제어되는 리소스는 "네이티브(native)" 리소스라고 지칭될 수 있다. 리소스 요청을 발행한 것이 아닌 프로세서에 의해 제어되는 리소스는 본원에서 "원격 리소스" 또는 "분배된 리소스"라고 지칭될 수 있다.
추가로, 원격 리소스에 대한 요청을 발행하는 것은 시간 지연 또는 레이턴시의 형태로 프로세싱 오버헤드를 발생한다. 즉, 특정 시간량이 프로세서들 사이에서 송신될 리소스 요청에 관련된 메시지 또는 메시지들에 대해 요구된다. 일부 경우들에서, 단일 리소스 요청은 다수의 프로세서-간 메시지들을 초래할 수 있다.
도 3은 PCD(100)의 소프트웨어 또는 하드웨어(또는 둘 모두)를 나타내는 기능 블록들을 포함하는 다이어그램이다. 라인 "A"의 왼쪽에 대한 블록들은 CPU(110A)에 의해 제어되는 PCD(100)의 리소스들을 나타낸다. 이러한 리소스들은: 또한 일반적으로 제1 하드웨어 엘리먼트(하드웨어 엘리먼트 #1)라고 지칭되는 CPU(110A) 그 자체; 또한 일반적으로 제2 하드웨어 엘리먼트(하드웨어 엘리먼트 #2)라고 지칭되는, CPU(110A)에 대한 클록(442); 또한 제3 하드웨어 엘리먼트(하드웨어 엘리먼트 #3)라고 지칭되는 버스 아비터 또는 스케쥴러(422); 또한 일반적으로 제1 소프트웨어 엘리먼트(소프트웨어 엘리먼트 #1)라고 지칭되는 버스 프로그램 A(444A); 또한 일반적으로 제2 소프트웨어 엘리먼트(소프트웨어 엘리먼트 #2)라고 지칭되는 버스 프로그램 B(444B); 일반적으로 제3 소프트웨어 엘리먼트(소프트웨어 엘리먼트 #3)라고 지칭되는 클록 프로그램 AHB; 및 일반적으로 키누름(448)으로써 나타나는 소프트웨어 엘리먼트에 의해 모니터링되는 동작 또는 기능을 포함할 수 있다.
CPU(110A)는 리소스들이 CPU(110A)의 메모리 공간 내에 있고, 보안 제한들과 같은, CPU(110A)가 그 리소스들에 액세스하는 것을 금지하는 어떠한 다른 제한들도 존재하지 않기 때문에, 위에서-인용된 리소스들을 제어하거나 위에서-인용된 리소스들에 대한 액세스를 가진다. 예를 들어, CPU(110A)는 그 리소스들의 하드웨어 레지스터들을 제어하거나 액세스할 수 있다. PCD(100)가 위에서-인용된 리소스들이 아닌 리소스들을 제어하거나 위에서-인용된 리소스들이 아닌 리소스들에 대한 액세스를 가지는 다른 CPU들(예를 들어, 도 2를 참조하라)을 포함할 수 있다는 점에 유의해야 한다.
컴퓨터 명령들의 라이브러리를 포함할 수 있는 프레임워크 매니저(440)는 리소스들의 기능성을 캡슐화하는 노드들을 관리한다. 즉, 노드들은 리소스들에 간접적으로 액세스하도록 액세스될 수 있다. 편의상, 리소스의 기능성을 캡슐화하는 노드는 리소스를 포함하는(including, comprising), 가지는 등으로서 본원에서 지칭될 수 있다. 각각의 노드는 하나 이상의 리소스들을 포함할 수 있다. 노드들은 소프트웨어 코드, 펌웨어 코드, 또는 유사한 매체에서 정의될 수 있고, 예를 들어, PCD(100)의 동작 동안 메모리(112)(도 1)에서 데이터 구조들로서 예시될 수 있다.
노드들(601)은 시작, 파워-업, 초기화, 부트-업 등의 시퀀스 동안, 또는 PCD(100)의 동작 동안 임의의 다른 적절한 시간에서 예시될 수 있다. 리소스를 예시하는, 리소스에 대한 요청을 발행하는, 또는 리소스와 다른 방식으로 상호작용하는 것에 대한 본원에서의 인용은 그 리소스를 포함하는 노드와 상호작용하는 것을 의미하는 것으로서 이해되어야 한다는 점에 유의해야 한다. 이 개시내용의 나머지에 대해, 포괄적 또는 비특정적 노드는 도 5를 참조하여 하기에 설명되는 바와 같이 참조 번호(601)로 표기될 것이다.
노드(601)는, 예를 들어, 일반적으로 제1 하드웨어 엘리먼트 또는 중앙 처리 장치(110)와 부합하는 단일 리소스를 가지는 제1 노드(602)를 포함할 수 있다. 이 개시내용에서 설명된 소프트웨어 아키텍쳐를 통해, 노드(601)의 각각의 리소스에는 하나 이상의 영숫자 캐릭터들을 포함하는 고유한 명칭이 제공될 수 있다. 도 3에 예시된 예시적인 실시예에서, 제1 노드(602)의 리소스에는 "core/cpu"의 리소스 명칭이 할당된다. 이러한 예시적인 리소스 명칭은 일반적으로 당업자에게 공지되어 있는 종래의 파일 네이밍에 대응한다. 그러나, 당업자에 의해 인식되는 바와 같이, 영-숫자 캐릭터들 및/또는 심볼들의 임의의 다른 결합을 포함하는 다른 타입들의 리소스 명칭들이 이 개시내용의 범위 내에 적절하게 존재한다.
노드들(601)은, 예를 들어, 복수의 리소스들을 가지는 제2 노드(622)를 더 포함할 수 있다. 이 예시적인 실시예에서, 제2 노드(622)는 버스 아비터 또는 스케쥴러(422)에 대응하는 단일 하드웨어 엘리먼트를 포함하는 제1 리소스를 가진다. 제2 노드(622)의 제2 리소스는 버스 프로그램 A(444A)의 제1 소프트웨어 엘리먼트에 일반적으로 대응하는 소프트웨어 엘리먼트를 포함한다. 제2 노드(622)의 제3 리소스는 일반적으로 버스 프로그램 B(444B)의 제2 소프트웨어 엘리먼트에 대응하는 또다른 소프트웨어 엘리먼트를 포함한다. 당업자는 주어진 노드(601)에 대한 리소스들의 임의의 결합과 임의의 수와 리소스 타입들이 이 개시내용의 범위 내에 적절하게 존재함을 인식한다.
도 3은 또한 일반적으로 2개의 소프트웨어 엘리먼트들(448, 450)의 동작 또는 기능에 대응하는 제1 클라이언트(648)를 예시한다. 도 3에 예시된 예시적인 실시예에서, 제1 클라이언트(648)는 일반적으로 휴대용 컴퓨팅 디바이스(100)에 의해 지원되는 특정 응용 프로그램 모듈(105) 내에서 발생할 수 있는 키누름 동작에 대응한다. 그러나, 당업자는 키 누름들이 아닌 소프트웨어 엘리먼트들의 다른 동작들 및/또는 기능들이 이 개시내용의 범위 내에 적절히 존재함을 인식한다. 클라이언트 요청들(648)과 이들의 각자의 생성에 관한 추가적인 상세항목들은 도 1과 관련하여 하기에 설명될 것이다.
도 3은 또한 특정한 아키텍쳐상의 엘리먼트들 간의 관계들을 예시한다. 예를 들어, 도 3은 클라이언트(648)와 제1 노드(602) 간의 관계를 예시한다. 구체적으로, 제1 클라이언트(648)는 리소스 "/core/cpu"를 포함하는 제1 노드(602)에 의해 관리되거나 핸들링되는, 점선들로 예시된 클라이언트 요청(675A)을 생성할 수 있다. 통상적으로, 미리 결정된 또는 설정된 수의 클라이언트 요청들(675)의 타입들이 존재한다. 클라이언트 요청들(675)은 도 11과 관련하여 하기에 더 상세하게 설명될 것이다.
도 3에 디스플레이된 다른 관계들은 점선들(680)을 이용하여 예시된 종속성들을 포함한다. 종속성들은 또다른 노드(601)의 각자의 리소스들 간의 관계들이다. 종속성 관계는 일반적으로, 제1 리소스(A)가 제1 리소스(A)에 정보를 제공할 수 있는 제2 리소스(B)에 의존함을 나타낸다. 이 정보는 제2 리소스(B)에 의해 수행되는 동작의 결과일 수 있거나, 이 정보는 단순히 제1 리소스(A)에 의해 요구되는 상태 정보를 포함할 수 있거나, 또는 이들의 임의의 결합일 수 있다. 제1 리소스(A) 및 제2 리소스(B)는 동일한 노드(601)의 일부분일 수 있거나 상이한 노드들(601)의 일부분일 수 있다. 클라이언트 요청들(675)이 전술된 키누름 동작의 예에서와 같이, 실행 스레드들로부터 뿐만 아니라 다른 노드들(601)로부터 기인할 수 있다는 점에 유의해야 한다. 종속적인 노드(601)로부터 정보를 획득하기 위해, 노드(601)는 클라이언트 요청(675)을 자신의 종속 노드(601)에 발행할 수 있다. 따라서, 종속성들을 나타내는 점선들(680)은 또한 잠재적인 클라이언트 요청들(675)의 방향을 나타낼 수 있다.
도 3에서, 제1 노드(602)는 제1 노드(602)를 통해 발신하여 622에서의 제2 노드로 확장하는 종속성 화살표(680B)에 의해 표시되는 바와 같이 제2 노드(222)에 종속적이다. 도 3은 또한, 제1 노드(602)가 또한 종속성 화살표(680A)에 의해 예시된 바와 같이 제3 노드(642)에 종속적임을 예시한다. 도 3은 또한 제2 노드(622)가 종속성 화살표(680C)에 의해 예시된 바와 같이 제4 노드(646)에 종속적임을 예시한다. 당업자는 도 3의 점선 화살표들로 예시된 종속성들(680)이 속성상 단지 예시적이며, 각자의 노드들(601) 간의 종속성들의 다른 결합들이 이 개시내용의 범위 내에 있다는 점을 인식한다.
프레임워크 매니저(440)는 도 3에 예시된 클라이언트 요청들(675)과 종속성들(680)을 포함하지만 이에 제한되지 않는, 전술된 관계들을 유지하는 역할을 한다. 종속성들과 같은 일부 이러한 관계들은 리소스들과 이들의 노드들(601)이 프레임워크 매니저(440)가 노드 인스턴트화(node instantiation) 프로세스를 시작하기 위해 PCD 시작 시간에서 액세스하는 PCD(100) 내의 소프트웨어 코드에서 정의되는 방식에 의해, 이러한 시작-시간(즉, 파워-업, 초기화, 부트-업 등)에서 이탈한다. 클라이언트 요청들(675)과 같은 다른 이러한 관계들은 응용 프로그램이 리소스를 불러오는 응용 프로그램 스레드의 실행 동안과 같이, 노드들(601)이 인스턴트화된 이후 발생한다. 클라이언트 요청들(675)이 (노드들(601)이 아닌 응용 프로그램 스레드들 또는 유사한 엘리먼트들(예를 들어, 클라이언트 요청(675A))을 실행하는 것으로부터 기인하든 또는 노드(601)로부터 기인하든지 간에, 클라이언트 요청들(675)은 프레임워크 매니저(440)를 통해 지시된다. 프레임워크 매니저(440)는 노드들(601) 간의 정보의 전달을 지시한다. 개념적으로, 프레임워크 매니저(440)는 다수의 스레드들이 노드들(601)과 본질적으로 동시에 통신할 수 있는 행렬로서의 역할을 한다. 상이한 스레드들이 상이한 데이터를 포함할 수 있지만, 동일한 프레임워크 매니저 소프트웨어 코드가 다수의 스레드들을 서비스할 수 있다.
하기에 더 상세하게 설명되는 바와 같이, 프레임워크 매니저(440)는 노드 종속적 노드들이 인스턴트화되자마자, 즉, 임의의 주어진 노드(601)에 대한 종속성들이 해결될 때 노드(601)를 인스턴트화할 수 있다. 프레임워크 매니저(440)는 PCD(100)의 소프트웨어 아키텍쳐에서 정의된 모든 노드들(601)을 인스턴트화하려고 시도한다. 종속성(680)은 종속성을 지원하는 리소스가 존재하거나 종속성(680)과 관련된 정보를 핸들링하기 위한 준비 상태에 있을 때 완전하거나 해결된다.
예를 들어, 단일 리소스 "/core/cpu"를 포함하는 제1 노드(602)는 단일 리소스 "/clk/cpu"를 포함하는 제3 노드가 제1 노드(602)와 제3 노드(642) 간에 존재하는 종속성 관계(680A)로 인해 인스턴트화되지 않은 경우, 프레임워크 매니저(440)에 의해 인스턴트화되지 않을 수 있다. 제3 노드(642)가 프레임워크 매니저(440)에 의해 인스턴트화되면, 이후 프레임워크 매니저(440)는 종속성 관계(680A)로 인해 제2 노드(602)를 인스턴트화할 수 있다.
프레임워크 매니저(440)가 노드의 종속성들(680) 중 하나 이상이 불완전하거나 해결되지 않기 때문에 특정 노드(601)를 인스턴트화할 수 없는 경우, 프레임워크 매니저(440)는 성공적으로 인스턴트화된 노드들(601)에 대응하는 단계들을 계속 수행하거나 실행할 것이다. 프레임워크 매니저(440)는 종속적인 리소스들이 생성되지 않은 불완전한 종속성들로 인해 존재하지 않을 수 있는 특정 노드(601)에 대한 호출을 통해 일반적으로 스킵(skip)하고, 그 불완전한 상태를 반영하는 해당 호출에 메시지들을 되돌릴 것이다.
도 1에 예시된 바와 같은 멀티-코어 환경에서, 프레임워크 매니저(440)는 도 1의 제0, 제1 및 제N 코어들(222, 224, 및 226)과 같은 별도의 코어들 상에서 노드들(601)을 생성하거나 인스턴트화할 수 있다. 노드들(601)은 일반적으로 별도의 코어들에 대한 멀티-코어 환경에서, 그리고 노드들(601)이 서로 종속적이지 않는 한, 그리고 특정 노드의 대응하는 종속성들 모두가, 하기에 설명되는 바와 같이, 완전한 경우, 병렬로 생성될 수 있다. 멀티-프로세서 환경에서, 노드들(601)은 도 1의 CPI(110A), 그래픽 프로세서(110B) 등과 같은 다양한 프로세서들 상에서 생성되거나 인스턴트화될 수 있다. 즉, 일부 노드들(601)이 하나의 프로세서의 메모리 공간 내에 존재할 수 있는 반면, 다른 노드들(601)은 또다른 프로세서의 메모리 공간 내에 존재할 수 있다. 그러나, 하나의 프로세서 상의 노드들(601)이 오직 프레임워크 매니저(440)를 통해서만 다른 프로세서 상의 노드들(601)에 대해 액세스가능하지 않을 수 있다는 점에 유의해야 한다.
전술된 (메인) 프레임워크 매니저(440)와 유사한 원격 프레임워크 매니저(300)는 프레임워크 매니저(440)와 병렬로 존재할 수 있다. 원격 프레임워크 매니저(300)는 상이한 프로세서들 상의 노드들(601) 간의 프로세서-간 전보 전달들을 조정하기 위해 프레임워크 매니저(440)와 협력하거나 또는 프레임워크 매니저(440)와 함께 작용한다. 즉, 원격 프레임워크 매니저(300)는 포함된 노드들(601)이 상이한 프로세서들 상에서 존재하는 경우들에서, 프레임워크 매니저(440)가 종속성들 및 클라이언트 요청들과 같은, 전술된 관계들을 유지하는 것을 보조한다.
따라서, 하나의 프로세서 상의 노드들(601)은 프레임워크 매니저들(440 및 300)의 결합된 효과를 통해 또다른 다른 프로세서 상의 노드들(601)에 대해 액세스가능하도록 만들어지지 않을 수 있다. 또한, 프레임워크 매니저들(440 및 300)의 결합은 포함된 노드들(601)가 동일한 프로세서 상에 존재하든 또는 상이한 프로세서들 상에 존재하든지 간에, 프레임워크 매니저(400)에 대한 이 개시내용에서 기술되는 기능들 모두를 수행할 수 있다. 이러한 멀티프로세서 실시예에서, 프레임워크 매니저들(300 및 440)이 포함하는 소프트웨어의 개별 복사본들은 프로세서들 각각의 도메인에 상주할 수 있다. 따라서, 각각의 프로세서는 동일한 프레임워크 매니저 소프트웨어에 대한 액세스를 가진다.
도 4는 편의상 DAG(directed acyclic graph)(400)의 형태로 전술된 노드들(602, 622, 642 및 646)을 재조직한다. 그래프(400)는 전술된 소프트웨어 아키텍쳐를 정의하는 또다른 방식이다. 그래프 이론의 어휘에 있어서, 그래프(400)의 꼭짓점들은 노드들(601)에 대응하고, 그래프(400)의 에지들은 클라이언트 요청들(675)에 대응하고, 인접한 노드들 또는 꼭짓점들은 리소스 종속성들을 나타낸다. 당업자는 그래프(400)가 종속성들의 결과로서 방향성 그래프이며, 프레임워크 매니저(400)가 사이클이 리소스 A가 리소스 B에 의존하고 리소스 B가 리소스 A에 의존하도록 정의되는 것을 방지하기 때문에 비순환적임을 인식할 것이다. 즉, 프레임워크 매니저(440)는 서로 의존하도록 (잘못되게) 정의된 2개의 노드들(601)을 인스턴트화하지 않을 것이다.
그래프의 비순환적 특징은, 하기에 설명되는 바와 같이, 각각의 노드(601)가 액세스될 때 (트랜잭션 프로세싱의 의미에서) 각각의 노드(601)가 잠기기 때문에, 데드록(deadlock)들을 방지하기 위해 중요하다. 2개의 노드들(601)이 제1 스레드가 액세스할 예정이고, 제2 스레드가 액세할 동시에 이들 2개의 노드들(601) 중 하나를 잠그고 이들 2개의 노드들(601) 중 다른 것을 잠그는 경우에 서로 의존할 경우, 두 스레드들 모두는 매달릴 것이다(hung).
그러나, 소프트웨어 개발자 또는 소프트웨어 아키텍쳐를 정의하는 것과 연루된 다른 이러한 사람이 서로 의존하는 2개의 리소스들을 소프트웨어 아키텍쳐에서 정의하는 것이 바람직하다고 간주하는, 상대적으로 드문 경우들에서, 두개(또는 그이상)의 리소스들은 서로 동일한 노드(601)에 포함될 수 있다. 동일한 노드 내의 2개의 리소스들은 동일한 잠금 상태를 공유할 것이다. 적어도 부분적으로는 이러한 이유로, 소프트웨어 개발자 또는 다른 이러한 사람이 아키텍쳐 내의 노드(622)와 같은 복수의 리소스 노드를 정의하도록 선택할 수 있다.
이 개시내용이, 명료성과 편리함의 목적으로, 노드(601)의 "리소스"라기 보다는 "노드"(601)를 인용할 수 있지만, 클라이언트 요청들이 노드들이 아닌 특정된 리소스들에 지시될 수 있다는 점이 이해되어야 한다. 다시 말해, 전술된 바와 같이 하나 이상의 리소스들의 기능성을 캡슐화하는 데이터 구조일 수 있는 노드(601)는 또다른 노드(601)와 같은 클라이언트 요청의 클라이언트 또는 다른 발행자의 관점에서 투명할 수 있다. 클라이언트의 관점에서, 요청은 노드라기보다는 리소스에 대해 발행된다. 마찬가지로, 클라이언트의 관점에서, 상태 질의, 이벤트, 또는 아키텍쳐의 다른 엘리먼트는 노드라기보다는 리소스와 연관된다.
예시적인 그래프(400)와 같은 리소스 그래프는 도 6-10에 관해 하기에 설명된, 종속성들에 따른 노드들(601)의 인스턴트화를 이해하는데 유용하다. 노드들(642 및 646)과 같은 리프 노드들은 리프 노드들이 종속성들을 가지지 않기 때문에, 비-리프 노드들에 앞서 인스턴트화된다. 일반적으로, 노드(601)는 그것에 의존하는 노드가 인스턴트화될 수 있기 전에 예시되어야 한다. 또한, 리소스 요청의 서비스가 꼭짓점들이 노드들(601)에 대응하고, 에지들이 클라이언트 요청들(675)에 대응하며, 인접한 노드들 또는 꼭짓점들이 리소스 종속성들을 나타내는 방향성 비순환 그래프를 횡단하는 것에 대응한다는 점을 알 수 있다.
멀티-프로세서 PCD(100)에서, 제1 프로세서는 제1 리소스 그래프에서 노드들(601)의 제1 세트에 대한 액세스를 가질 수 있거나 노드들(601)의 제1 세트를 제어할 수 있는 반면, 제2 프로세서는 제2 리소스 그래프 내의 노드들(601)의 제2 세트에 대한 액세스를 가질 수 있거나, 노드들(601)의 제2 세트를 제어할 수 있고, 여기서, 제1 및 제2 리소스 그래프들은 어떠한 리소스들도 공유하지 않는데, 즉, 제1 및 제2 리소스 그래프들은 리소스들에 대해 상호 배타적이다. 즉, 이러한 환경에서, 각각의 프로세서는 다른 프로세서들에 대해 액세스가능하지 않은 리소스들과 다른 엘리먼트들 간의 관계들을 정의하는 고유한 리소스 그래프를 가진다. 본 개시내용의 분배된 리소스 관리는, 둘 이상의 프로세서들 각각이 자신의 고유한 리소스 그래프에서 리소스들에 대한 액세스를 가지고 다른 프로세서들의 리소스 그래프들에서의 리소스들에 대한 액세스를 가지지 않는 경우들에서, 종속성들 및 클라이언트 요청들과 같은, 전술된 관계들의 유지와 관련된다.
리소스들에 대한 액세스에 대한 위에서-인용된 제한은, 일부 실시예들에서, 하드웨어 구성에 의해 제한된다. 즉, 프로세서는 프로세서가 레지스터와 같은 하드웨어 디바이스에 영향을 줄 수 있는 어떠한 수단도 가지지 않을 수 있는데, 왜냐하면, 하드웨어 디바이스가 또다른 프로세서에 의해 또는 또다른 프로세서의 메모리 공간 내에서 제어되기 때문이다. 대안적으로, 또는 추가로, 리소스들에 대한 액세스에 대한 제한은 보안성 위험들(예를 들어, 또다른 프로세서를 감염시킬 수 있는 바이러스)에 대한 프로세서의 노출을 최소화하기 위한 것과 같은 이유들로, 소프트웨어에 부과될 수 있다.
도 5는 도 1의 PCD(100)의 리소스들을 관리하는 시스템에 대한 소프트웨어 아키텍쳐(500B1)의 또다른 양상의 일반적인 다이어그램이다. 이 양상은 관련된 모든 리소스들과 다른 엘리먼트들이 동일한 프로세서에 의해 제어되는 PCD(100) 및 아키텍쳐의 상황에서 명료함의 목적으로 설명되는데, 즉, 관련된 모든 리소스들 및 다른 엘리먼트들이 동일한 리소스 그래프에 포함된다. 이러한 일반적인 다이어그램에서, 각각의 노드(601)의 하나 이상의 리소스들에는 고유한 명칭들이 제공되지 않는다. 도 5의 노드 또는 리소스 그래프(500B1)는 오직 노드들(601), 클라이언트들(648), 이벤트들(690), 및 아키텍쳐 또는 프레임워크 매니저(440)에 의해 지원되는 질의 기능들(695)만을 포함한다. 각각의 노드(601)는 타원 형상 및 노드(601) 내의 자원들 간의 각자의 종속성들을 나타내는 특정 방향들을 가지는 화살표들(680)로 예시되어 있다.
도 5는 또한 제1 노드(601A)의 클라이언트(648)가 제1 노드(601A)에 클라이언트 요청(675)을 발행할 수 있는 방법을 예시한다. 이들 클라이언트 요청들(675)이 발행된 이후, 제2 노드(601B)는 이벤트(690)를 트리거링하거나 또는, 이벤트(690)와 질의(695)에 대응하는 메시지들이 클라이언트(648)로 다시 흐르는 질의(695)에 대한 응답을 제공할 수 있다.
도 6은 도 1의 PCD(100)의 리소스들을 관리하는 시스템에 대한 소프트웨어 아키텍쳐(500B1)의 전술된 양상의 더 구체적인 다이어그램이다. 도 6은 오직 특정한, 그러나 예시적인 리소스 명칭들을 가지는 노드들(601), 뿐만 아니라, 도 3에 대응하는 클라이언트들(648), 이벤트들(690), 및 질의 기능들(695)을 포함하는 노드 또는 리소스 그래프(500B2)를 예시한다. 각각의 노드(601)는 타원 형상 및 노드(601) 내의 리소스들 간의 각자의 종속성들을 나타내는 특정 방향들을 가지는 화살표들(680)로 예시되어 있다.
예를 들어, 제1 노드(602)는 제1 노드(602)가 제2 노드(622)의 3개의 리소스들에 종속적임을 표시하기 위해 종속성 화살표(680B)를 가진다. 유사하게, 제2 소프트웨어 엘리먼트(444B)를 포함하며 일반적으로 도 11C에서 참조 문자 "C"를 가지고 표기된 제3 리소스 "/bus/ahb/sysB/"는 이러한 제3 리소스(C)가 제4 노드(646)의 단일 "/clk/sys/ahb" 리소스에 대해 종속적임을 표시하는 종속성 화살표(680C)를 가진다.
도 6은 하나 이상의 이벤트들(690) 또는 질의 기능들(695)을 포함할 수 있는 노드들(601)로부터의 출력 데이터를 예시한다. 질의 기능(695)은 이벤트(690)와 유사하다. 질의 기능(695)은 고유할 수 있거나 고유하지 않을 수 있는 질의 핸들을 가질 수 있다. 질의 기능은 일반적으로 외부적으로 식별되지 않으며, 일반적으로 질의 기능은 상태를 가지지 않는다. 질의 기능(695)은 노드(601)의 특정 리소스의 상태를 결정하기 위해 사용될 수 있다. 질의 기능(695) 및 이벤트들(690)은 설정된 클라이언트(648)와의 관계들을 가질 수 있고, 이들 관계들은 각자의 이벤트(690) 및 질의 기능(695)으로부터의 정보가 특정 클라이언트(648)에 전달됨을 표시하기 위해 방향성 화살표들(697)에 의해 표현된다.
도 5-6의 노드 또는 리소스 그래프들(500B)은 프로세서의 제어 하에 메모리에 존재하며 프레임워크 매니저(440)에 의해 관리되는 관계들을 나타낸다. 노드 또는 리소스 그래프(500B)는 프레임워크 매니저(440)에 의해 관리되는 각자의 엘리먼트들 간의 관계들을 식별하기 위한 그리고 소프트웨어 팀에 의한 고장진단(troubleshoot)을 위한 유용한 툴로서 프레임워크 매니저(440)에 의해 자동으로 생성될 수 있다.
도 7은 PCD(100)의 리소스(들)를 관리하기 위한 소프트웨어 구조들을 생성하거나 인스턴트화하기 위한 방법(1000A)을 예시하는 흐름도이다. 이 방법은 관련된 모든 리소스들 및 다른 엘리먼트들이 동일한 프로세서에 의해 제어되는 아키텍쳐의 상황에서 명료성의 목적으로 설명되는데, 즉, 관련된 모든 리소스들 및 다른 엘리먼트들이 동일한 리소스 그래프에 포함된다.
블록(1005)는 PCD(100)의 리소스들을 관리하기 위한 방법 또는 프로세스(1000)의 제1 루틴이다. 블록(1005)에서, 루틴은 노드 구조 데이터를 수신하기 위해 프레임워크 매니저(440)에 의해 실행되거나 수행될 수 있다. 노드 구조 데이터는 특정 노드(601)가 다른 노드들(601)과 가질 수 있는 종속성들을 개요화하는 종속성 어레이를 포함할 수 있다. 노드 구조 데이터와 이러한 루틴 또는 서브방법(1000)에 관한 추가적인 상세항목들은 도 9와 관련하여 하기에 더 상세하게 설명될 것이다.
다음으로, 블록(1010)에서, 프레임워크 매니저(440)는 블록(1005)에서 수신된 노드 구조 데이터의 일부분인 종속성 데이터를 리뷰할 수 있다. 결정 블록(1015)에서, 프레임워크 매니저(440)는 노드 구조 데이터가 리프 노드(601)를 정의하는지를 결정할 수 있다. 리프 노드(601)는 일반적으로, 도 3-4에서의 노드들(642 및 646)과 같이, 노드 구조 데이터에 기초하여 생성될 노드가 어떠한 종속성들도 가지지 않음을 의미한다. 결정 블록(1015)에 대한 질의가, 현재 노드를 생성하기 위한 노드 구조 데이터가 어떠한 종속성들도 가지지 않음을 의미하는, 긍정인 경우, 프레임워크 매니저(440)는 루틴 블록(1025)으로 계속한다.
결정 블록(1015)에 대한 조사가 부정인 경우, "아니오" 분기는 프레임워크 매니저가 노드 구조 데이터 내의 모든 하드 종속성들이 존재하는지를 결정하는 결정 블록(1020)으로 후속된다. 하드 종속성은 리소스가 하드 종속성 없이 존재하는 것을 포함할 수 있다. 반면, 소프트 종속성은 리소스가 선택적 단계로서 종속적 리소스를 사용할 수 있는 것을 포함할 수 있다. 소프트 종속성은 소프트 종속성을 가지는 노드(601) 또는 노드(601)의 리소스가 심지어 소프트 종속성이 존재하지 않을 때에도 노드 아키텍쳐 내에서 생성되거나 인스턴트화될 수 있음을 의미한다.
소프트 종속성의 예는 다수의 리소스들을 포함하는 리소스 발신 노드에 대한 동작에 대해 중요하지 않은 최적화 특징을 포함할 수 있다. 프레임워크 매니저(440)는 심지어 소프트 종속성이 생성되지 않은 소프트 종속성들을 가지는 노드들 또는 리소스들 대해 존재하지 않을 때에도 존재하는 모든 하드 종속성들에 대한 노드 또는 리소스를 생성하거나 인스턴트화할 수 있다. 회신 특징은 소프트 종속성을 참조하기 위해 사용될 수 있고, 따라서, 소프트 종속성이 프레임워크 매니저(440)에 대해 이용가능해질 때, 프레임워크 매니저(440)는 소프트 종속성들이 현재 이용가능하다는 소프트 종속성을 참조하는 각각의 회신을 통지할 것이다.
결정 블록(1020)에 대한 조사가 부정적인 경우, "아니오" 분기는 노드 구조 데이터가 프레임워크 매니저(440)에 의해 메모리와 같은 임시 스토리지에 저장되는 블록(1027)으로 후속하고, 프레임워크 매니저(440)는 이 인스턴트화되지 않은 노드와 연관된 회신 특징을 생성한다.
결정 블록(1015)에 대한 조사가 긍정적인 경우, "예" 분기가 노드(601)가 루틴 블록(1005)에서 수신된 노드 구조 데이터에 기초하여 생성되거나 인스턴트화된 루틴(1025)으로 후속한다. 루틴 블록(1025)의 추가적인 상세항목들은 도 9와 관련하여 하기에 설명될 것이다. 다음으로, 블록(1030)에서, 프레임워크 매니저(440)는 자신의 고유한 리소스 명(들)을 사용하여 새롭게 생성된 노드(601)를 공표하고, 따라서 다른 노드들(601)은 새롭게 생성된 노드(601)에 정보를 송신하거나 새롭게 생성된 노드(601)로부터 정보를 수신할 수 있다.
이제 도 7의 계속 흐름도인 도 8을 참조하면, 블록(1035)에서, 프레임워크 매니저(440)는 새롭게 생성된 노드(601)가 인스턴트화되었고 정보를 수신하거나 전송할 준비가 되었음을, 새롭게 생성된 노드(601)에 종속적인 다른 노드들(601)에 통지한다. 일 예시적인 양상에 따르면, 통지들은 도 5의 노드(601B)와 같은 종속적인 노드가 생성될 때 즉시 트리거링되는데, 즉, 통지들이 반복적으로 수행된다. 따라서, 도 5의 노드(601B)가 구성되는 경우, 노드(601A)는 즉시 통지된다. 이러한 통지는 (노드(601B)가 노드(601A)의 마지막 종속성이었기 때문에) 노드 B(601A)가 구성되게 할 수 있다. 노드(601B)의 구성은 다른 노드들(601B)이 통지되도록 할 수 있는 등의 식이다. 노드(601B)는 노드(601B)에 종속적인 최종 리소스가 완료될 때까지 완료되지 않는다.
제2의 약간 더 복잡한 구현예는 모든 통지들을 별도의 통지 큐에 두고, 이후 단일 시점에서 시작하는 큐를 통해 실행하는 것인데, 즉, 통지들은 반복적으로 수행된다. 따라서, 도 5의 노드(601B)가 구성될 때, 노드(601A)에 대한 통지가 리스트 상에 푸시된다. 이후, 그 리스트가 실행되고 노드(601A)가 통지된다. 이것은 다른 추가적인 노드들(601)(도 6에 예시되지 않은, 노드(601A) 이외의)에 대한 통지가 동일한 리스트 상에 배치되게 하고, 그 통지는 이후 노드(601A)에 대한 통지가 송신된 후에 송신된다. (노드(601A)에 대한 통지 이외의) 다른 노드들(601)의 통지들은 노드(601B)와 노드(601A)와 연관된 모든 작업이 완료된 이후까지도 발생하지 않는다.
논리적으로, 이들 2개의 구현예들은 등가이지만, 이들은 실행될 때 상이한 메모리 소모 특징들을 가진다. 반복적인 구현은 단순하지만, 임의의 양의 스택 공간을 소모할 수 있으며, 스택 소모는 종속성 그래프의 깊이의 함수이다. 반복적 구현은 약간 더 복잡하며, 약간 더 정적인 메모리(통지 리스트)를 요구하지만, 스택 사용은 도 5에 예시된 바와 같이, 종속성 그래프의 깊이와는 무관하게 일정하다.
또한, 블록(1035)의 노드 생성의 통지는 다른 노드들에 대해 제한되지 않는다. 이는 또한, 다른 명칭의 구성을 위해 내부적으로 사용될 수 있다. 시스템(500A) 내의 일부 임의의 엘리먼트는 단지 다른 노드들이 아니라, 노드가 이용가능해질 때 통지를 위해 요청하기 위해 동일한 메커니즘을 사용할 수 있다. 노드들과 비-노드들 모두 동일한 통지 메커니즘을 사용할 수 있다.
결정 블록(1040)에서, 프레임워크 매니저(440)는 다른 노드들(601) 또는 소프트 종속성들이 현재 노드(601)의 생성에 기초한 생성과 인스턴트화를 위해 릴리즈되는지를 결정한다. 특정 종속성 관계들(680)이 최근에 생성 또는 인스턴트화를 겪은 현재 노드에 의해 이행되었기 때문에, 결정 블록(1040)은 일반적으로 리소스들이 생성될 수 있는지를 결정할 수 있다.
결정 블록(1040)에 대한 조사가 긍정적인 경우, "예" 분기는, 방금 생성된 노드(601)에 의한 종속성의 이행으로 인해 릴리즈된 노드(601)가 이제 생성되거나 인스턴트화될 수 있는 루틴 블록(1025)에 다시 후속한다.
결정 블록(1040)에 대한 조사가 부정적인 경우, 프레임워크 매니저(440)가 도 2에 예시된 바와 같이 소프트웨어 아키텍쳐의 엘리먼트들 사이의 통신들을 관리할 수 있는 블록(1045)으로 후속한다. 다음으로, 블록(1050)에서, 프레임워크 매니저(440)는, 특정 리소스와 연관된 리소스 명칭들을 사용함으로써 리소스들에 의해 취해진 동작들을 계속 로깅하거나 레코딩할 수 있다. 블록(1045)은 프레임워크 매니저(440) 또는 리소스들, 노드들(601), 클라이언트들(648), 이벤트들(695) 및 질의 기능들(697)과 같은, 프레임워크 매니저(440)에 의해 관리되는 엘리먼트들 중 임의의 것에 의해 취해진 임의의 동작 이후에, 프레임워크 매니저(440)에 의해 실행될 수 있다. 블록(1045)은 노드(601)의 리소스와 같은 특정 엘리먼트를 생성한 권위자들에 의해 제공되는 고유한 식별자 또는 명칭에 따라 각각의 엘리먼트에 의해 수행되는 동작들을 열거하는 동작의 실행 로그를 유지할 수 있는 노드 아키텍쳐의 또다른 양상을 도시한다.
종래 기술에 비교하면, 시스템의 각각의 리소스에 할당된 고유한 명칭들을 열거하는 블록(1050)에서의 활동의 이러한 로깅은 고유하며, 디버깅과 에러 고장진단에서 사용되는 것과 같은 중요한 장점들을 제공할 수 있다. 노드 아키텍쳐(500A)의 또다른 고유한 양상은, 각각의 팀이 덜 중요하게 번역할 표들을 생성하고, 일반적으로 다른 팀들 및/또는 OEM(original equipment manufacturer)에 의해 할당된 리소스 명칭들을 혼동할 필요 없이 고유하며 트래킹하기 용이한 리소스 명칭들을 사용할 수 있도록 별도의 팀들이 서로 독립적으로 상이한 하드웨어 및/또는 소프트웨어 엘리먼트들 상에서 작용할 수 있다는 점이다.
다음으로, 결정 블록(1055)에서, 프레임워크 매니저(440)는, 프레임워크 매니저(440)에 의해 레코딩된 활동의 로그가 요청되었는지를 결정한다. 결정 블록(1055)에 대한 조사가 부정적인 경우, "아니오" 분기는 프로세스가 루틴(1005)으로 다시 되돌아가는 프로세스의 종단으로 후속한다. 결정 블록(1055)에 대한 조사가 긍정적인 경우, "예" 분기는 프레임워크 매니저(440)가 중요한 리소스 명칭들 및 프린터 또는 디스플레이 스크린 및/또는 둘 모두와 같은 출력 디바이스에 리소스 명칭들에 의해 수행되는 각자의 동작들을 송신하는 블록(1060)으로 후속한다. 프로세스는 이후 전술된 루틴 블록(1005)으로 되돌아간다.
도 9는 PCD(100)의 소프트웨어 아키텍쳐를 정의하는 노드 구조 데이터를 수신하기 위한 도 7의 서브-방법 또는 루틴(1005)을 예시하는 흐름도이다. 수신 방법은 예를 들어, PCD(100)가 시작하거나 초기화될 때와 같이, 임의의 적절한 시간에 발생할 수 있다. 이러한 경우, 노드 구조 데이터는 프로세서가 아키텍쳐에 따라 노드들(601)을 인스턴트화하기 위한 준비에서 메모리로부터 대응하는 소프트웨어 코드를 판독할 때 수신된다.
블록(1105)은 도 7의 서브 방법 또는 루틴(1005)에서의 제1 단계이다. 블록(1105)에서, 프레임워크 매니저(440)는 도 7의 CPU(110) 및 클록(442)과 같은 소프트웨어 또는 하드웨어 엘리먼트에 대한 고유한 명칭을 수신할 수 있다. 이전에 논의된 바와 같이, 노드(601)는 적어도 하나의 리소스를 참조해야 한다. 각각의 리소스는 시스템(500A)에서 고유한 명칭을 가진다. 시스템(500A) 내의 각각의 엘리먼트는 고유한 명칭을 이용하여 식별될 수 있다. 각각의 엘리먼트는 캐릭터 관점에서 고유한 명칭을 가진다. 다시 말해, 일반적으로, 동일한 명칭을 가지는 시스템(500A) 내에 2개의 엘리먼트들이 존재하지 않는다. 시스템의 예시적인 양상들에 따르면, 노드들(601)의 리소스들이 일반적으로 시스템에 대한 고유한 명칭들을 가질 수 있지만, 클라이언트 또는 이벤트 명칭들이 고유하도록 요구되지는 않음에도, 클라이언트 또는 이벤트 명칭들은 원하는 경우 고유할 수 있다.
편의상, 고유한 명칭들을 생성하기 위해 순방향 슬래시"/" 캐릭터들을 사용하는 종래의 트리 파일 네이밍 구조 또는 파일 네이밍 "메타포"가 사용될 수 있는데, 예컨대 CPU(110)에 대해서는 "/core/cpu"가 그리고 클록(442)에 대해서는 "/clk/cpu"가 사용될 수 있다. 그러나, 당업자에 의해 인식되는 바와 같이, 영숫자 캐릭터들 및/또는 심볼들의 임의의 다른 결합을 포함하는 다른 타입들의 리소스 명칭들이 이 개시내용의 범위 내에 적절하게 존재한다.
다음으로, 블록(1110)에서, 프레임워크 매니저(440)는 생성된 노드(601)의 하나 이상의 리소스들과 연관된 하나 이상의 드라이버 기능들에 대한 데이터를 수신할 수 있다. 드라이버 기능은 일반적으로 특정 노드(601)에 대한 하나 이상의 리소스들에 의해 완료될 동작을 포함한다. 예를 들어, 도 6에서, 노드(602)의 리소스 /core/cpu에 대한 드라이버 기능은 요청된 프로세싱의 요청된 양을 제공하기 위해 그것이 요청하는 CPU 클록 주파수와 버스 대역폭의 양을 요청할 수 있다. 이들 요청들은 노드들(642) 및 노드(622) 내의 리소스들의 클라이언트들을 통해 이루어질 것이다. 노드(642) 내의 /clk/cpu에 대한 드라이버 기능은 일반적으로 그것이 노드(602)의 /core/cpu 리소스로부터 수신한 요청에 따라 물리적 클록 주파수를 실제로 세팅하는 역할을 담당할 것이다.
블록(1115)에서, 프레임워크 매니저(440)는 노드 속성 데이터를 수신할 수 있다. 노드 속성 데이터는 일반적으로 보안성(노드가 사용자 공간 애플리케이션들을 통해 액세스될 수 있음), 원격성(노드가 시스템 내 다른 프로세서들로부터 액세스될 수 있음), 및 액세스가능성(리소스가 다수의 동시적인 클라이언트들을 지원할 수 있음)과 같은 노드 정책들을 정의하는 데이터를 포함한다. 프레임워크 매니저(440)는 또한 리소스가 요청 평가 또는 로깅 정책과 같은 디폴트 프레임워크 행동을 무효화하게 하는 속성들을 정의할 수 있다.
후속적으로, 블록(1120)에서, 프레임워크 매니저(440)는 생성되는 특정 노드(601)에 대한 커스터마이즈된(customized) 사용자 데이터를 수신할 수 있다. 사용자 데이터는 "C" 프로그래밍 언어에 관해 당업자에 의해 이해되는 바와 같이 보이드 "스타(star)" 필드를 포함할 수 있다. 사용자 데이터는 또한 "나를 신뢰하시오" 필드로서 당업자에게 공지되어 있다. 예시적인 커스터마이즈 사용자 데이터는, 주파수 테이블들, 레지스터 맵들 등과 같은 테이블들을 포함할 수 있지만 이에 제한되지 않는다. 블록(1120)에서 수신된 사용자 데이터는 시스템(500B)에 의해 참조되지 않지만, 커스터마이제이션이 프레임워크 매니저(440)에 의해 인식되거나 완전히 지원되지 않는 경우 리소스의 커스터마이제이션을 허용한다. 이러한 사용자 데이터 구조는 특별한 또는 특정한 사용들에 대해 확장되도록 의도된 "C" 프로그래밍 언어에서의 기본 클래스이다.
당업자는 특별한 클래스의 특정 사용들을 확장하기 위한 다른 종류의 데이터 구조들이 이 개시내용의 범위 내에 있음을 인식한다. 예를 들어, "C++"(C-플러스-플러스)의 프로그래밍 언어에 있어서, 등가적인 구조는 노드(601) 내의 리소스에 대한 확장 메커니즘이 될 키워드 "공중"을 포함할 수 있다.
다음으로, 블록(1125)에서, 프레임워크 매니저(440)는 종속성 어레이 데이터를 수신할 수 있다. 종속성 어레이 데이터는 생성되는 노드(6010)가 종속되는 하나 이상의 리소스들(6010)의 고유하고 특정한 명칭들을 포함할 수 있다. 예를 들어, 도 6의 제1 노드(601)가 생성된 경우, 이 블록(1125)에서, 종속성 어레이 데이터는 제2 노드(622)의 3개의 리소스들의 리소스 명칭들 및 제1 노드(602)가 종속되는 제3 노드(642)의 단일 리소스 명칭을 포함할 수 있다.
후속적으로, 블록(1130)에서, 프레임워크 매니저(440)는 리소스 어레이 데이터를 수신할 수 있다. 리소스 어레이 데이터는, 이러한 제1 노드(602)가 생성된 경우, 도 7b-7c의 제1 노드(602)에 관련된 파라미터들과 같은, 생성되는 현재 노드에 대한 파라미터들을 포함할 수 있다. 리소스 어레이 데이터는 후속하는 데이터들: 다른 리소스들의 명칭들; 유닛; 최댓값; 리소스 속성들; 플러그-인 데이터; 및 블록(1120)의 커스터마이즈 사용자 데이터와 유사한 임의의 커스터마이즈된 리소스 데이터 중 하나 이상을 포함할 수 있다. 플러그-인 데이터는 일반적으로 소프트웨어 라이브러리로부터 리트리브된 기능들을 식별하고, 일반적으로 생성되는 특별한 노드 또는 복수의 노드들에 의해 지원될 수 있는 클라이언트 타입들을 열거한다. 플러그-인 데이터는 또한 클라이언트 생성 및 파괴의 커스터마이제이션을 허용한다. 블록(1130) 이후, 프로세스는 도 7의 블록(1010)으로 되돌아간다.
도 9에서, 속성 데이터 블록(1115), 커스터마이즈된 사용자 데이터 블록(1120), 및 종속성 어레이 데이터 블록(1125)은 이들 특별한 단계들이 선택적이며 임의의 주어진 노드(601)에 대해 요구되지 않음을 나타내기 위해 점선들로 예시되어 있다. 한편, 고유한 명칭 블록(1115), 드라이버 기능 블록(1110), 및 리소스 어레이 데이터 블록(1130)은 루틴(1005)의 이들 단계들이 일반적으로 노드(601)를 생성하기 위해 중요함을 나타내기 위해 실선들로 예시되어 있다.
도 10은 PCD(100)에 대한 소프트웨어 아키텍쳐에서 노드를 생성하기 위한 도 7의 서브-방법 또는 루틴(1025)을 예시하는 흐름도이다. 루틴 블록(1205)은 일 예시적인 실시예에 따라 노드(601)를 인스턴트화하거나 생성하기 위한 서브-방법 또는 루틴(1025)에서의 제1 루틴이다. 루틴 블록(1205)에서, 인스턴트화된 노드(601)와 연관된 하나 이상의 클라이언트들(648)이 이 단계에서 생성된다. 루틴 블록(1205)에 관한 추가적인 상세항목들은 도 11에 관련하여 하기에 더 상세하게 설명될 것이다.
블록(1210)에서, 프레임워크 매니저는 블록(705)의 노드 구조 데이터에 대응하는 하나 이상의 리소스들을 생성하거나 인스턴트화할 수 있다. 다음으로, 블록(1215)에서, 프레임워크 매니저(440)는 루틴 블록(1005)의 루틴 블록(1110)에서 수신된 드라이버 기능들을 활성화할 수 있다. 일 예시적인 양상들에 따르면, 드라이버 기능들은 루틴 블록(1005)의 리소스 어레이 데이터 블록(1130)에서 수신된 최댓값들을 사용하여 활성화될 수 있다. 또다른 선호되는 예시적인 양상에 따르면, 각각의 드라이버 기능은 루틴(1005)으로부터 노드 구조 데이터와 함께 전달되는 선택적인 초기 값을 이용하여 활성화될 수 있다. 초기 데이터가 제공되지 않는 경우, 드라이버 기능은 0 - 최솟값 - 에서 초기화된다. 드라이버 기능은 또한 그것이 초기화되고 있다고 알려지는 방식으로 일반적으로 활성화된다. 이것은 리소스가 초기화에 대해 특정적인 임의의 동작들을 수행하게 할 수 있지만, 정상적인 또는 루틴 동작 동안 수행될 필요는 없다. 프로세스는 이후 도 7의 단계(1030)로 되돌아간다.
도 11은 PCD(100)의 소프트웨어 아키텍쳐에서 클라이언트(648)를 생성하거나 인스턴트화하기 위한 도 10의 서브-방법 또는 루틴(1205)을 예시하는 흐름도이다. 블록(1305)은 하나 이상의 리소스들(601)의 클라이언트가 생성되는 루틴 블록(1205)의 제1 단계이다. 블록(1205)에서, 프레임워크 매니저(440)는 생성된 클라이언트(648)에 할당된 명칭을 수신한다. 리소스 명칭들과 유사하게, 클라이언트(648)에 대한 명칭은 임의의 타입의 영숫자 및/또는 심볼들을 포함할 수 있다.
다음으로, 블록(1310)에서, 생성된 이 클라이언트(648)에 대한 임의의 특별한 커스터마이제이션이 존재하는 경우, 커스터마이즈된 사용자 데이터가 프레임워크 매니저(440)에 의해 수신될 수 있다. 블록(1310)은 단계가 선택적임을 나타내기 위해 점선들로 예시되어 있다. 블록(1310)의 커스터마이즈된 사용자 데이터는 노드들(601)의 리소스들의 생성과 관련하여 위에서 논의된 커스터마이즈된 사용자 데이터와 유사하다.
블록(1315)에서, 프레임워크 매니저(440)는 생성되는 특별한 클라이언트에 할당된 클라이언트 타입 카테고리를 수신한다. 이러한 기록에 대한 클라이언트 타입 카테고리는 4개 타입들: (a) 요구됨, (b) 임펄스, (c) 벡터, 및 (d) 등시성 중 하나를 포함할 수 있다. 클라이언트 타입 카테고리 리스트는 시스템(101)에 의해 관리된 리소스들에 따라 그리고 노드들(601)의 리소스들에 의존하는 응용 프로그램들에 따라 확장될 수 있다.
요구된 카테고리는 일반적으로 요구되는 클라이언트(648)로부터 특별한 리소스로 전달된 스칼라 값의 프로세싱과 부합한다. 예를 들어, 요구된 요청은 특정 개수의 MIP(millions of instructions per second)들을 포함할 수 있다. 반면, 임펄스 카테고리는 일반적으로 시작 시간 또는 중단 시간의 임의의 표기 없이 특정 시간 기간 내에서 일부 활동을 완료하기 위한 요청의 프로세싱과 부합한다.
등시성 카테고리는 일반적으로 통상적으로 재발하는 동작에 대한 요청과 부합하며, 적절하게-정의된 시작 시간과 적절하게-정의된 종료 시간을 가진다. 벡터 카테고리는 일반적으로 직렬로 또는 병렬로 요구되는 다수의 동작들의 일부분인 데이터의 어레이와 일반적으로 부합한다.
후속적으로, 블록(1320)에서, 프레임워크 매니저(440)는 클라이언트(648)가 동기식으로 지정되는지 또는 비동기식으로 지정되는지를 나타내는 데이터를 수신한다. 동기식 클라이언트(648)는 통상적으로, 데이터 및 리소스(601)가 동기식 클라이언트(648)로부터 요청된 작업의 완료를 끝냈다는 표시를 리소스(601)가 되돌릴 때까지 프레임워크 매니저(440)가 노드(601)의 리소스를 잠그도록 요구하는 것이다.
반면, 비동기식 클라이언트(648)는 프레임워크 매니저(440)에 의해 액세스되는 하나 이상의 스레드들에 의해 병렬로 핸들링될 수 있다. 프레임워크(440)는 스레드에 대한 회신을 생성할 수 있고, 회신이 각자의 스레드에 의해 실행될 때 값을 되돌릴 수 있다. 당업자는 비동기식 클라이언트(648)가 동기식 클라이언트(648)의 작업이 실행될 때동기식 클라이언트(648)와 같은 리소스를 잠그지 않음을 인식한다.
블록(1320)에서, 결정 블록(1325)에서, 프레임워크 매니저(440)는, 클라이언트(645)에 의해 식별된 리소스가 이용가능한지를 결정한다. 결정 블록(1325)에 대한 조사가 부정적인 경우, "아니오" 분기는 클라이언트(648)가 이 시간에 생성될 수 없음을 나타내는 널 값 또는 메시지가 되돌아가는 블록(1330)으로 후속한다.
결정 블록(1325)에 대한 조사가 긍정적인 경우, "예" 분기는, 클라이언트(648)에 의해 식별되는 각각의 리소스가 블록(1310)에서 제공되는 클라이언트 타입을 지원하는지를 결정하는 결정 블록(1335)으로 후속한다. 결정 블록(1335)에 대한 조사가 부정적인 경우, "아니오" 분기는 클라이언트(648)가 이 시간에 생성될 수 없음을 나타내는 널 값 또는 메시지가 되돌아가는 블록(1330)으로 다시 후속한다.
결정 블록(1335)에 대한 조사가 긍정적인 경우, "예" 분기는 프레임워크 매니저(440)가 메모리 내의 클라이언트(648)를 생성하거나 인스턴트화하는 블록(1340)으로 후속한다. 다음으로, 블록(1345)에서, 선택적인 인수들과 같은 임의의 커스터마이즈된 사용자 데이터가 블록(1310)에서 수신되는 경우, 이들 선택적인 인수들은 자신의 각자의 리소스들을 가지고 특정 노드(601)에 매핑될 수 있다. 다음으로, 블록(1350)에서, 새롭게 생성된 클라이언트(645)는 전술된 바와 같이 유휴 상태에서 또는 요청된 상태에서 대응하는 하나 이상의 리소스들에 커플링된다. 프로세스는 이후 도 10의 블록(1210)으로 되돌아간다.
도 12는 PCD(100)에 대한 소프트웨어 아키텍쳐에서 리소스(601)에 대해 클라이언트 요청(675)을 생성하기 위한 방법(1400)을 예시하는 흐름도이다. 방법(1400)은 일반적으로, 도 7-11과 관련하여 전술된 바와 같이 클라이언트 및 노드 생성(인스턴트화) 이후에 실행된다.
블록(1405)은 리소스(601)에 대한 클라이언트 요청(675)을 생성하기 위한 방법(1400)에서의 제1 단계이다. 방법(1400)은 후속하는 3가지 타입들의 클라이언트 요청들(675): (a) 요구됨, (b) 임펄스, 및 (c) 벡터가 프레임워크 매니저(440)에 의해 핸들링되는 방법을 설명할 것이다. 위에서 언급된 요청들(675)의 명칭들이 제안하는 바와 같이, 클라이언트 요청들(675)은 일반적으로 위에서 생성되고 설명된 클라이언트 타입들에 부합한다.
블록(1405)에서, 프레임워크 매니저(440)는 위에서 언급된 3가지: (a) 요구됨, (b) 임펄스, 및 (c) 벡터 중 하나와 같은 특정 클라이언트 요청(675)과 연관된 데이터를 수신할 수 있다. 요구된 요청과 연관된 데이터는 일반적으로 요구된 클라이언트(648)로부터 특별한 리소스(601)에 전달된 스칼라 값을 포함한다. 예를 들어, 요구된 요청은 특정 개수의 MIP(millions of instructions per second)를 포함할 수 있다. 임펄스 요청은 시작 시간 또는 중단 시간에 대한 임의의 표기 없이 특정 시간기간 내에 일부 활동을 완료하기 위한 요청을 포함한다.
벡터 요청에 대한 데이터는 일반적으로 직렬로 또는 병렬로 완료되도록 요구되는 다수의 동작들의 어레이를 포함한다. 벡터 요청은 임의의 길이의 값들을 포함할 수 있다. 벡터 요청은 일반적으로 사이즈 값 및 값들의 어레이를 가진다. 노드(601)의 각각의 리소스는 벡터 요청을 지원하기 위해 포인터 필드를 가지도록 확장될 수 있다. "C" 프로그래밍 언어에서, 포인터 필드는 당업자에 의해 이해될 바와 같이 유니온 함수에 의해 지원된다.
다음으로, 블록(1410)에서, 프레임워크 매니저(440)는 도 11과 관련하여 전술된 방법에 의해 생성된 클라이언트(648)를 통해 요청을 발행한다. 후속적으로, 블록(1415)에서, 프레임워크 매니저(440)는 요청이 요구되는 타입 또는 벡터타입인 경우 클라이언트를 통해 전달되는 요청 데이터를 이중 버퍼링(double buffering)한다. 요청이 임펄스 타입인 경우, 블록(1415)은 프레임워크 매니저(440)에 의해 스킵된다.
요구된 요청들에 대해, 이 블록(1415)에서, 이전 요청으로부터의 값들은 프레임워크 매니저(440)가 요청된 값들의 현재 세트에서의 이전에 요청된 값들 간의 임의의 차이가 존재하는지를 결정할 수 있다. 벡터 요청들에 대해, 이전 요청들은 일반적으로 메모리에 유지되지 않지만, 노드(601)의 리소스는 특정 구현예에 대해 요구되는 경우, 그것을 유지할 수 있다. 따라서, 블록(1415)은 벡터 타입들의 요청들에 대해 선택적이다.
블록(1420)에서, 프레임워크 매니저(440)는 요청된 값들의 현재 세트에서 요청된 값들의 이전 세트 간의 델타 또는 차이를 계산한다. 결정 블록(1425)에서, 프레임워크 매니저는 요청된 값들의 현재 세트가 요청된 값들의 이전 세트와 동일한지를 결정한다. 다시 말해, 프레임워크 매니저(440)는 요청된 값들의 현재 세트와 요청된 값들의 이전 세트 사이에 차기가 존재하는지를 결정한다. 요청된 값들의 현재 세트와 이전 세트 사이의 차이가 존재하지 않는 경우, "예" 분기는 (블록들(1430) 내지 블록(1470)을 스킵하고) 프로세스가 종료하는 블록(1475)으로 후속한다.
결정 블록(1425)에 대한 조사가, 요청된 값들의 세트가 이전에 요청된 값들의 세트에 비해 상이함을 의미하는, 부정적인 경우, "아니오" 분기는 결정 블록(1430)으로 진행한다.
결정 블록(1430)에서, 프레임워크 매니저(440)는 현재 요청이 비동기식 요청인지를 결정한다. 결정 블록(1430)에 대한 조사가 부정적인 경우, "아니오" 분기는 클라이언트 요청(675)에 대응하는 리소스가 프레임워크 매니저(440)에 의해 잠기는 블록(1440)으로 후속한다. 결정 블록(1430)에 대한 조사(1430)가, 현재 요청이 비동기식 요청 타입임을 의미하는, 긍정적인 경우, "예" 분기는 요청이 또다른 스레드 내로 푸시될 수 있고, 도 1에서와 같은 멀티-코어 시스템이 프레임워크 매니저(440)에 의해 현재 관리되는 경우 또다른 코어에 의해 실행될 수 있는 블록(1435)으로 진행한다. 블록(1435)은 PCD(100)가 단일 코어 중앙 처리 시스템인 경우 이 단계가 선택적일 수 있음을 나타내는 점선으로 예시되어 있다.
후속적으로, 블록(1440)에서, 요청(675)에 대응하는 리소스들(601)은 프레임워크 매니저(440)에 의해 고정된다. 다음으로, 블록(1445)에서, 리소스(601)는 일반적으로 도 9의 블록(1130)에서 수신된 리소스 어레이 데이터의 플러그-인 데이터에 대응하는 업데이트 기능을 실행한다. 업데이트 기능은 일반적으로 새로운 클라이언트 요청의 견지에서 새로운 리소스 상태를 담당하는 기능을 포함한다.
업데이트 기능은 자신의 이전 상태를 클라이언트 요청에서의 요청된 상태와 비교한다. 요청된 상태가 이전 상태보다 더 큰 경우, 업데이트 기능은 클라이언트 요청을 수행할 것이다. 그러나, 요청된 상태가 현재 상태와 같거나 더 작고 리소스가 여기서 동작하는 경우, 클라이언트 요청은, 오래된 상태가 요청된 상태를 달성하거나 만족시키기 때문에 효율성을 증가시키기 위해 수행되지 않을 수도 있다. 업데이트 기능은 클라이언트로부터 새로운 요청을 취하고, 리소스에 대한 새로운 상태를 결정하기 위해 새로운 요청을 다른 활성 요청들과 함께 집합화한다.
예로서, 다수의 클라이언트는 버스 클록 주파수를 요청할 수 있다. 버스 클록에 대한 업데이트 기능은 일반적으로 모든 클라이언트 요청들의 최댓값을 취하고, 버스 클록에 대한 새로운 원하는 상태로서 그것을 사용할 것이다. 모든 리소스들이 동일한 업데이트 기능을 사용하는 경우가 아니더라도, 다수의 리소스들에 의해 사용될 일부 업데이트 기능들이 존재한다. 일부 공통적인 업데이트 기능들은 클라이언트 요청들의 최댓값을 취하고, 클라이언트 요청들의 최솟값을 취하고, 클라이언트 요청을 합산하는 것이다. 또는 리소스가 일부 고유한 방식으로 요청들을 집합화할 필요가 있는 경우, 리소스들은 자신만의 커스텀 업데이트 기능을 정의할 수 있다.
다음으로, 블록(1450)에서, 프레임워크 매니저(440)는 클라이언트(648)에 대응하는 리소스에 데이터를 전달하고, 따라서 리소스는 노드(601)의 리소스에 대해 특정적인 드라이버 기능을 실행할 수 있다. 드라이버 기능은 업데이트 기능에 의해 계산되는 바와 같이 리소스 상태를 적용한다. 이것은 하드웨어 세팅들을 업데이트하는 것, 종속적인 리소스들에 대한 요청들을 발행하는 것, 리거시 기능들을 호출하는 것, 또는 위 항목의 일부 결합을 내포할 수 있다.
이전 예에서, 업데이트 기능은 요청된 버스 클록 주파수를 계산한다. 드라이버 기능은 그 요청된 주파수를 수신할 수 있고, 드라이버 기능은 그 주파수에서 실행하도록 클록 주파수 제어 HW를 업데이트할 수 있다. 때때로, 드라이버 기능이 업데이트 기능이 계산된 정확한 요청된 상태를 만족시키는 것이 가능하지 않다는 점에 유의한다. 이 경우, 드라이버 기능은 요청을 최상으로 만족시키는 주파수를 선택할 수 있다. 예를 들어, 버스 클록 HW는 오직 128 MHz 및 160 MHz에서만 실행할 수 있지만, 요청된 상태는 150 MHz일 수 있다. 이 경우, 드라이버 기능은, 요청된 상태를 초과하는 것으로서, 160 MHz에서 실행되어야 한다.
다음으로, 블록(1455)에서, 프레임워크(440)는 블록(1450)에서 드라이버 기능을 실행한 리소스로부터 상태 제어를 수신한다. 후속적으로, 블록(1460)에서, 리소스에 대해 정의된 경우, 이벤트들(690)은 데이터가 이벤트(690)에 대응하는 클라이언트(648)에 다시 전달되도록 트리거링될 수 있다. 이벤트들은 또다른 스레드에서 프로세싱될 수 있다. 이는 잠긴 리소스들을 이용하여 소모되는 시간량을 최소화할 수 있고, 도 1에 예시된 바와 같이 멀티-코어 시스템에서 병렬 동작을 허용한다.
하나 이상의 이벤트들(690)은 요청이 이 방법(1400)에서 설명된 리소스에 대해 정의될 수 있는 방법과 유사한 방식으로 리소스에 대해 정의될 수 있다. 다시 말해, 이벤트 생성 프로세스는 클라이언트 생성 프로세스와 거의 병렬일 수 있다. 이벤트들과 상이한 한가지 점은 특정 임계들이 교차될 때만 트리거링된 이벤트들을 정의하는 것이 가능하다는 점이다.
오직 임계들에 기초하여 트리거링된 이벤트들의 이러한 정의는 자원이 과도 가입될 때 - 이는 시스템 오버로딩 조건을 나타냄 - , 또는 리소스가 로우/오프가 될 때 - 이는 다른 것들이 셧 오프되고, 시스템이 과도 가입될 때 디스에이블된 기능성을 복원하는 등을 허용할 수 있음 - 에 대한 통지를 허용한다. 이벤트 등록이 임계들을 이용하여 등록될 수 있기 때문에, 이는 실제로 필요한 것이 존재할 때만 발행할 이벤트 통지에 대해 시스템이 수행해야 할 작업량을 감소시킨다. 또한, 모든 상태 변경에 대한 이벤트에 대해 등록하는 것이 가능하다.
다음으로, 선택적 블록(1465)에서, 프로세싱된 요청이 벡터 요청인 경우, 이 선택적 블록(1465)은 일반적으로 수행된다. 선택적 블록(1465)은 일반적으로 벡터 포인터가 사용자가 벡터 내로 전달한 동일한 데이터에 여전히 위치되는지를 평가하기 위한 체크 또는 결정을 포함한다. 이러한 선택적 블록(1465)에 대한 조사가, 포인터가 사용자에 의해 벡터 내로 전달된 동일한 데이터를 여전히 지정함을 의미하는, 긍정적인 경우, 포인터는 구 데이터에 대한 참조들이 유지되지 않도록 클리어아웃(clear out)된다. 이러한 선택적 블록(1465)은 일반적으로, 임펄스 요청과 요구된 요청에 비해, 벡터 요청이 프로세싱될 때 전술된 배가 버퍼링 블록(1415)을 고려하도록 수행된다.
후속적으로, 블록(1470)에서, 프레임워크(440)는, 다른 클라이언트 요청들(648)이 특별한 노드(601)의 현재의 그러나 이제 릴리즈된 요청된 리소스에 의해 핸들링될 수 있도록, 요청된 리소스를 잠금해제한다. 프로세스는 이후 다음 클라이언트 요청을 수신하기 위해 제1 블록(1405)으로 되돌아간다.
전술된 방법들 및 데이터 구조들은 이들이 단일-프로세서 PCD(100)에 대해 존재하는만큼 본질적으로 멀티-프로세서 PCD(100)에 대해 적용가능하다. 그러나, 원격 프레임워크(300)(도 3)는 멀티-프로세서 실시예에서의 동작을 향상시킬 수 있는 추가적인 특징들을 제공할 수 있다.
예를 들어, 원격 프레임워크(300)는 유리하게는, 애플리케이션 프로그래머 또는 유사한 사람에 대해 투명한 프로세서-간 통신의 상세항목들을 렌더링할 수 있다. 따라서, 응용 프로그램은, 예를 들어, 그 리소스를 제어하는 프로세서 도메인의 임의의 식별을 클라이언트 정의 내에 포함시켜야 할 필요 없이 타겟 리소스에 대한 요청을 발행하는 클라이언트를 정의할 수 있다. 오히려, 원격 프레임워크(300)는 어느 프로세서가 클라이언트를 제어하는지 그리고 어느 프로세서가 타겟 리소스를 제어하는지와는 무관하게 요청이 타겟 리소스에 도달함을 보장한다.
추가로, 원격 프레임워크(300)는 예를 들어, 응용 프로그램이 프로세서들 간의 통신 경로들(예를 들어, 버스들)의 프로토콜 또는 다른 양상들에 관련된 임의의 명령들을 포함할 필요가 없도록 프로세서-간 통신을 관리한다. 또한, 상이한 프로세서-간 통신 경로들이 상이한 프로토콜들을 사용할 수 있음에 따라, 원격 프레임워크(300)는 리소스 정의가 리소스의 다른 양상들과 함께 프로토콜을 특정하게 한다. 분배된 리소스 관리에 관련된 이들 및 다른 특징들이 도 13에 관련하여 하기에 설명된다.
도 13은 제1 프로세서(미도시됨)에 의해 제어되는 제1 리소스(1302)가 제2 프로세서(미도시됨)에 의해 제어되는 제2 리소스(1304)에 대응하는 분배된 또는 원격 리소스로서 역할을 하는 예 또는 경우를 예시한다. 용어 "분배된 리소스" 또는 "원격 리소스"는 또다른 프로세서 상의 "네이티브" 리소스에 대응하는 하나의 프로세서 상의 리소스를 지칭하도록 이 개시내용에서 사용된다. 이 예에서 제2 리소스(1304)는 제2 프로세서에 대한 네이티브 리소스로서 역할을 한다.
분배된 리소스는 대응하는 네티이브 리소스에 액세스하기 위한 수단으로서 사용될 수 있다. 이 예에서, 용어 "리소스"는 리소스가 노드에 포함될 수 있는 것으로 이해되어야 함에 따라, 용어 "노드"와 상호교환가능하게 사용될 수 있다.
파선(1301)은 제1 프로세서에 의해 제어되는 리소스들(선(1301)의 왼쪽으로)과 제2 프로세서에 의해 제어되는 리소스들(선(1301)의 오른쪽으로) 사이의 분할을 예시한다. 제1 리소스(1302)는 제1 프로세서에 의해 제어되는 둘 이상의 리소스들 중 하나이다. 한 가지 이러한 리소스는 제1 리소스(1302)가 의존하는 프로토콜 리소스(1306)일 수 있다. 마찬가지로, 제2 리소스(1304)는 제2 프로세서에 의해 제어되는 둘 이상의 리소스들 중 하나이다. 한 가지 이러한 리소스는 제2 리소스(1304)가 의존하는 프로토콜 리소스(1308)일 수 있다.
제1 및 제2 리소스들(1302 및 1306)은 또한 일반적으로 리소스들 또는 노드들에 관해 전술된 바와 동일한 방식으로 추가적인 리소스들에 의존할 수 있지만, 이러한 추가적인 리소스들은 명료성의 목적으로 도 13에 도시되지 않는다. 제1 프로세서에 의해 제어되는 리소스들이 제1 리소스 그래프(즉, 방향성 비순환성 그래프)에 의해 정의되고, 제2 프로세서에 의해 제어되는 리소스들이 제1 리소스 그래프와 어떠한 리소스들도 공유하지 않는 제2의 이러한 리소스 그래프에 의해 정의된다는 점에 유의한다.
제1 및 제2 리소스들(1302 및 1304)은, 이들의 각자의 프로세서들의 제어 하에, 통신 경로(1303)를 통해 정보를 통신할 수 있다. 통신 경로(1303)는 제 및 제2 프로세서들과 물리적 매체를 통해 통신하기 위해 사용되는 트랜스포트 프로토콜들의 하나 이상의 계층들 사이의 물리적 매체의 결합을 나타낸다. 따라서, 제1 리소스(1302)와 제2 리소스(1304) 사이의 임의의 통신들은 프로토콜들에 따라야 한다. 프로토콜 리소스들(1306 및 1308)은 프로토콜을 정의하거나, 또는 라이브러리(미도시됨) 내의 프로토콜 정의에 지정할 수 있다. 원격 프레임워크(300) 및 (메인) 프레임워크(440)는 이들 간의 리소스들과 통신들을 관리하기 위해 서로 관련하여 동작한다. 하기에 설명된 바와 같이, 클라이언트(1312)는, 제1 프로세서의 제어 하에, 제1 리소스(1302)에 대한 하나 이상의 리소스 요청들을 발행할 수 있다. 제1 리소스(1302)는 리소스 요청에 대한 대응하는 제2 리소스(1304)의 기능성을 사용한다.
상이한 애플리케이션 상태들에서, 프로세서가 리소스들의 상이한 구성들 또는 상태들을 요청하기에 필수적이거나 바람직할 수 있다. 예를 들어, 버스 리소스는 버스 클록의 속도를 제어할 수 있다. 하나의 애플리케이션 상태에서, 프로세서는 프로세서가 예를 들어, 100 MIPS(million instructions per second)의 레이트에서 동작하게 하는 버스 클록을 요청할 수 있는 반면, 또다른 애플리케이션 상태에서, 프로세서는 프로세서가 예를 들어, 150 MIPS의 레이트에서 동작하게 하는 버스 클록을 요청할 수 있다. 슬립 상태인 애플리케이션 상태로 진입할 된 준비가 된 프로세서의 경우, 프로세서는 제로 MIPS의 버스 클록을 요청할 수 있다.
유사하게, 제1 응용 프로그램을 실행하는 프로세서에 의해 정의된 제1 애플리케이션 상태에서, 프로세서는 100 MIPS를 요청할 수 있는 반면, 제2 응용 프로그램을 실행하는 프로세서에 의해 정의된 또다른 애플리케이션 상태에서, 프로세서는 150 MIPS를 요청할 수 있다. 마찬가지로, 특정 개수의 응용 프로그램들을 동시에 실행하는 프로세서에 의해 정의된 하나의 애플리케이션 상태에서, 프로세서는 100MIPS를 요청할 수 있는 반면, 상이한 개수의 응용 프로그램들을 동시에 실행하는 프로세서에 의해 정의되는 제2 애플리케이션 상태에서, 프로세서는 150 MIPS를 요청할 수 있다. 위에서-인용된 버스 클록이 리소스 요청을 발행하는 프로세서에 의해 구성될 수 있는 리소스의 예로서만 의도되며, 또한, 수들 "100" 및 "150"은 프로세싱 속도의 임의의 예들로서 의도된다는 점이 이해되어야 한다.
리소스 구성들 또는 상태들은 리소스 상태 세트들로 그룹화될 수 있다. 리소스 상태 세트는 특정 프로세서 애플리케이션 상태에서 프로세서에 의해 함께 사용되는 하나 이상의 리소스들의 구성들 또는 상태들을 정의한다. 예를 들어, 특정 리소스 상태 세트는 프로세서에 특정 수의 MIP의 속도를 제공하기 위한 버스 클록 리소스에 대한 구성 또는 상태 정보, 및 프로세서에 디코딩 기능을 제공하기 위해 디코더에 대한 구성 또는 상태 정보(즉, 리소스의 또다른 예)를 포함할 수 있다.
도 14는 제어기(101), 리소스 전력 매니저(157), 마스터 프로세서들(110, 126), 로우-레벨 드라이버들(103), 공유된 리소스들(105A-C), 및 시스템(103)을 형성하는 로컬 리소스들(105D-H) 간의 관계들을 예시하는 기능 블록도이다. 도 14는 또한 터치스크린(132)이 터치스크린 드라이버/제어기(130)에 커플링될 수 있는 방법을 예시한다. 터치스크린 드라이버/제어기(130)는 제1 마스터 프로세서(110A)의 클록 코드(113A)에 커플링될 수 있다.
시스템(103)은 리소스 레이턴시를 최소화하는 방식으로 프로세서(110)에 의해 요구되는 리소스 상태 세트들 사이에서 스위칭할 수 있다. 용어 "리소스 레이턴시"는 마스터 프로세서(110, 126)가 제어기(101)와 리소스 전력 매니저(157)가 또다른 리소스 상태 세트로 트랜지션하도록 준비하기 시작하는 시간과, 그 세트의 리소스들이 특정된 상태들로 구성되어 프로세서에 의해 사용될 준비가 되는 시간 사이에 발생하는 지연 또는 레이턴시를 지칭한다. 하기에 설명되는 바와 같이, 리소스 상태 세트들은, 응용 프로그램들을 실행하고 다른 방식으로 프로세싱 전력을 제어할 시에 프로세서를 보조하도록 구성되는 리소스들이 프로세서에 제공되는 활성 리소스 상태 세트들; 및 프로세서가 슬립 상태에서 유지할 시에 프로세서를 보조하는 리소스들만이 프로세서에 제공되는 슬립 상태, 즉, 프로세서가 응용 프로그램들을 실행하지 않거나 또는 다른 방식으로 프로세싱 전력을 제공하지 않는 상태로 넓게 카테고리화될 수 있다. 슬립 상태인 프로세서가 로우-레벨 기능들을 유지할 수 있지만, 프로세서는 당업자에 의해 응용 프로그램인 것으로 이해될 소프트웨어를 실행하지 않는다. 하기에 설명된 "다음-활성 상태" 특징은, 임의의 리소스 상태 세트들이 활성 세트일 수 있는지 또는 슬립 세트일 수 있는지와는 무관하게, 임의의 리소스 상태 세트들 사이의 트랜지션들에 적용될 수 있다는 점이 이해되어야 한다.
도 14에 도시된 예시적인 실시예에서, 제1 마스터 프로세서(110A)는 리소스 전력 관리자(157)와 제어기(101)에 커플링될 수 있다. 제어기(101)는 제1 마스터 프로세서(110A)의 클록 코드(113A)에 커플링될 수 있다. 제어기(101)는 하나 이상의 로우-레벨 드라이버들(103)을 포함할 수 있다. 하나 이상의 로우-레벨 드라이버들(103)은 하나 이상의 공유된 리소스들(105A-C)과 통신하는 역할을 할 수 있다. 공유된 리소스들(105A-C)은 마스터 프로세서(110)의 작업들 또는 기능들을 지원하는 임의의 타입의 디바이스를 포함할 수 있다. 공유된 리소스들(105A-C)은 다른 프로세서들의 클록들 뿐만 아니라 그래픽 프로세서들, 디코더들 등과 같은 단일 기능 엘리먼트들과 같은 디바이스들을 포함할 수 있다.
공유된 리소스들(105A-C)은 하나 이상의 로컬 리소스들(105D-H)에 커플링될 수 있다. 하나 이상의 로컬 리소스들(105D-H)은 하나 이상의 로컬 리소스들(105D-H)이 마스터 프로세서(110)의 작업들 또는 기능들을 지원하거나 보조하는 임의의 타입의 디바이스를 포함할 수 있는 점에 있어서 공유된 리소스들(105A-C)과 유사할 수 있다. 로컬 리소스들(105D-H)은 다른 프로세서들의 클록들 뿐만 아니라, 그래픽 프로세서들, 디코더들 등과 같은 단일 기능 엘리먼트들과 같은 디바이스들을 포함할 수 있다. 로컬 리소스들(105D-H)은 리프 노드들을 포함할 수 있다. 리프 노드들은 일반적으로 다른 종속적인 리소스들(105)을 지칭하거나 포함하지 않는 로컬 리소스들(105D-H)로서 당업자에 의해 이해된다.
제어기(101)는 하나 이상의 마스터 프로세서들(110, 126)로부터 발행된 요청들을 관리하는 역할을 할 수 있다. 예를 들어, 제어기(101)는 제1 마스터 프로세서(110A)로부터 기인한 요청을 관리할 수 있다. 제1 마스터 프로세서(110A)는 운용자가 터치스크린(132)을 조작하는 것에 응답하여 이 요청을 발행할 수 있다. 터치스크린(132)은 터치스크린 드라이버/제어기(130)에 대해 신호들을 발행할 수 있다. 터치스크린 드라이버/제어기(130)는 차례로 신호들을 제1 마스터 프로세서(110A)의 클록 코드(113A)에 발행할 수 있다.
제어기(101)는 또한 특별한 프로세서(110)에 대한 슬립 상태들을 관리하는 역할을 할 수 있다. 슬립 상태에 진입하기 이전에, 프로세서(110)는 슬립 상태들을 관리하기 위한 정보를 제공할 것이다. 슬립 상태들을 관리하기 위한 정보는 슬립 상태로의 진입과 슬립 상태로부터의 이탈을 포함한다. 슬립 상태들을 관리하기 위한 이러한 정보는 트리거들 및 리소스 상태들로서 하기에 지칭될 것이다. 리소스 상태 세트는 프로세서의 슬립 상태를 지원하는 방식으로 하나 이상의 리소스들을 구성하기 위한 리소스 정보를 포함할 수 있다.
트리거들은 프로세서(110)가 슬립 상태로 진입하거나 슬립 상태를 이탈하게 하는 이벤트들을 정의할 수 있다. 트리거들은 일반적으로 제어기(101) 내에 포함되거나 제어기(101)에 의해 액세스될 수 있는 리소스 상태들을 참조할 것이다. 리소스 상태들은 특정 프로세서(101)에 의해 요구되는 리소스들(105)의 원하는 상태를 정의한다. 예시적인 실시예에서, 각각의 프로세서(110)는 제어기(101)에 적어도 2개의 리소스 상태 세트들, 다시 말해 리소스 상태들의 활성 세트 및 리소스 상태들의 슬립 세트를 제공할 수 있다.
그러나, 다른 실시예들에서, 프로세서(110)는 단일 활성 세트 및 단일 슬립 세트와는 상이한 단일 활성 세트 및 단일 슬립 세트 또는 리소스 상태 세트들에 더하여 리소스 상태 세트들을 제공할 수 있다. 이러한 다른 리소스 상태 세트들은 전술된 프로세서 애플리케이션 상태들 중 하나 이상에 대응할 수 있다. 다시 말해, 임의의 애플리케이션 상태에 대해, 프로세서는 대응하는 리소스 상태 세트를 제공할 수 있다.
예시적인 실시예에서, 리소스 상태들의 활성 세트는 프로세서(110)가 프로세싱 기능들을 활성으로 수행하고 자신의 리소스들(105)로부터 동작/기능들을 요구할 때 리소스들(105)의 상태들을 정의할 수 있다. 리소스 상태들의 슬립 세트는 프로세서(110)가 슬립 또는 유휴 상태에 있을 때 리소스들(105)의 상태들을 정의할 수 있다. 트리거들 및 리소스 상태들에 관한 추가적인 상세항목들은 도 15에 관련하여 하기에 설명될 것이다.
도 15는 제어기(101), 리소스 세트들(304), 및 트리거 세트들(314)에 관한 상세항목들을 예시하는 기능 블록도이다. 이전에 주지된 바와 같이, 제어기(101)는 PCD(100)의 프로세서들(110, 126) 중 하나 이상에 의해 실행되는 소프트웨어를 포함할 수 있다. 제어기(101)는 메모리(112)에 또는, 당업자에 의해 이해되는 바와 같이 로컬 스토리지와 같은, 제어기(101) 내의 영역에 정보를 저장할 수 있다. 이 정보는 제어기(101)에 의해 서비스되는 각각의 마스터 프로세서(110)에 할당되는 리소스 세트들(304)을 포함하는 리소스 테이블(302)을 포함할 수 있다. 이 정보는 또한 각각의 마스터 프로세서(110)에 할당되며 각각의 마스터 프로세서(110)에 대해 고유할 수 있는 트리거 세트들(314)을 또한 포함할 수 있다.
각각의 리소스 세트(304)는 일반적으로 특정 마스터 프로세서(110)에 의해 요구되는 리소스들(105)의 상태들에 관련된 정보를 포함한다. 특정 마스터 프로세서(110)에 할당된 각각의 리소스 세트(304)는 활성 리소스 세트(306) 및 슬립 리소스 세트(308)를 포함할 수 있다. 활성 리소스 세트(306)는 특정 마스터 프로세서(110)가 활성이거나 정상적으로 기능할 때 리소스들(105)의 상태들을 정의하거나 설명할 수 있다. 당업자에 의해 이해되는 바와 같이, 슬립 리소스 세트(308)는 특정 마스터 프로세서가 슬립 또는 휴지 상태에 있을 때 리소스들(105)의 상태들을 정의하거나 설명할 수 있다. 각각의 마스터 세트(304)는 또한 도 15에 예시된 예시적인 실시예에서 제1 마스터 프로세서(110)에 할당된 "세트 1" 및 "세트 2"와 같은 추가적인 세트들을 포함할 수 있다.
예로서, 도 15에 예시된 바와 같은 제1 마스터 프로세서(A)(110A)에 대한 활성 리소스 세트(306)는 자신의 리소스들(105) 각각에 대해 후속하는 값들을 할당받는데; 제1 공유된 리소스(SR#1)(105A)에 대해 값은 1이고; 제2 공유된 리소스(SR#2)(105B)에 대한 값은 1이고; 제N 공유된 리소스(SR#N)(105C)에 대한 값은 1인 반면; 제1 로컬 리소스(LR#1)(105D)에 대한 4개의 값들은 0, 1, 0 및 1이다.
이전에 주지된 바와 같이, 리소스들(105)의 상태들은 단일 값들에 제한되지 않으며, 복수의 값들을 포함할 수 있다. 또한, 리소스들의 상태들은 다수의 상이한 타입들의 파라미터들 중 임의의 것을 포함할 수 있다. 예를 들어, 상태는 리소스(105)로서 기능할 수 있는 특정 클록의 클록 속도의 양에 대해 수백 메가헤르츠를 지정할 수 있다.
또다른 예로서, 도 15에 예시된 바와 같은 제1 마스터 프로세서(A)(110A)에 대한 슬립 리소스 세트(308A)에는 그것의 리소스들(105) 각각에 대해 후속하는 값들을 할당하고; 제1 공유된 리소스(SR#1)(105A)에 대해, 이 리소스에는 제로의 값이 할당되고; 제2 공유된 리소스(SR#2)(105B)는 제로의 할당된 값을 가지는 반면; 제N 공유된 리소스(SR#N)(105C)는 제로의 할당된 값을 가진다. 제1 로컬 리소스(LR#1)(105D)에는 0, 1, 0 및 1의 값들이 할당될 수 있다.
특정 마스터 프로세서(110)에 할당된 각각의 트리거 세트(314)는 적어도 3개의 필드들, 즉, 인터럽트 필드(316); "세트로부터"(318); 및 "세트로 가기"(320)를 포함할 수 있다. 트리거 세트(314)의 이들 3개의 필드들 각각은 또한 3개의 열들, 즉, 트리거 시작 열(322); 클리어 열(324); 및 타이머 열(326)을 포함할 수 있다.
인터럽트 필드(316)는 리소스 전력 매니저(157)에 의해 생성되고 그리고/또는 검출될 수 있는 동작 또는 활동을 설명한다. 인터럽트 필드(316)는 일반적으로, 제어기(101)가 RPM(157)에 의해 검출된 트리거 이벤트에 기초하여 특정 프로세서(110)에 의해 요구되는 특정 리소스 세트(304)를 선택하게 할 수 있는 "트리거 이벤트"로서 특성화될 수 있다. 리소스 세트(304)의 선택은 배경 섹션에서 전술된 시간 소모적 소프트웨어 핸드쉐이크를 회피할 수 있다.
제1 마스터 프로세서(A)(110A))에 대해 도 15의 제1 트리거 세트(트리거 세트 #1)를 리뷰한 경우, 세트의 필드들은 열들에 의해 순서대로 논의된다. 트리거 세트(314A)의 제1 열을 이용하여 시작한 경우, 트리거 시작 열(322)은 인터럽트 필드(316)에 대응하는 제1 행에서 "디코드 인터럽트"로서 열거된 동작을 가진다.
앞서 주목된 바와 같이, 중단 필드(316)는 제어기(101)가 트리거 시작 필드(322)의 검출에 응답하여 리소스 세트(304)의 상태들을 활성화하게 하는 파라미터들을 정의할 수 있다. 도 15에 예시된 예시적인 실시예에서, 중단 필드(316A)는 리소스 전력 매니저(110)가 PCD(100)가 비디오를 디코딩할 때와 같이, 리소스 전력 매니저(110)가 "디코드 인터럽트"를 검출할 때, 이 이벤트는 "트리거 시작" 열 하에서 제1 열(322A1) 내의 "세트로부터" 필드(318)를 리뷰하도록 제어기(101)에 통지할 수 있다.
"세트로부터" 필드(318)는 현재 리소스 세트(304)가 제어기(101)에 의해 리뷰된 특정 마스터 프로세서(110)에 대해 무엇이어야 하는지를 나타내는 값을 포함할 수 있다. 이 필드(318)는 "활성 세트", "슬립 세트"와 같은 식별자, 또는 "세트 1" 또는 "세트 2"와 같은 세트 번호에 의해 리소스 세트(304)를 열거할 수 있다. 필드(320)는 별표와 같은 "와일드 카드"를 포함할 수 있다.
"세트로부터" 필드(318)에서의 와일드카드 표기는 제어기(101)가 특정 마스터 프로세서(101)에 의해 사용된 마지막으로 공지된 활성 리소스 세트(304)를 리트리브(retrieve)하게 할 수 있다. 도 15에 예시된 예시적인 실시예에서, "세트로부터" 행(318A) 및 트리거 시작 열(322A1)은 별표 또는 와일드카드의 값을 가진다.
"세트로 가기"(320)는, "세트로부터"(318)와 같이, "활성 세트", "슬립 세트"와 같은 식별자, 또는 "세트 1" 또는 "세트 2"와 같은 세트 번호에 의해 리소스 세트(304)의 리스팅을 포함할 수 있다. 필드(320)는 또한 프로세서(110)에 의해 활용되는 마지막 리소스 세트(304)를 의미하는 별표와 같은 "와일드 카드"를 포함할 수 있다. 도 15에 예시된 예시적인 실시예에서, "세트로 가기" 필드(320A) 및 트리거 시작 필드 열(322A1)은 제1 리소스 세트(304A)의 열(310A)에 열거된 리소스 세트 1인 "세트 1"의 값을 가진다.
도 15에 예시된 예에 대해, 디코드 인터럽트 이벤트가 RPM(157)에 의해 검출될 때, 이는 제어기(101)에 통지한다. 제어기(101)는 제1 마스터 프로세서에 대한 제1 트리거 세트를 리뷰한다. 트리거 시작 열(322A1)이 매칭하는 값(디코드 인터럽트)을 열거하기 때문에, 제어기(101)는 "세트로부터" 필드(318A)를 리뷰하고 값이 와일드카드 값 또는 별표임을 결정한다. 제어기(101)는 이후, 특정 리소스 세트(304A)를 지정하는 "세트 1"의 값을 가지는 "-로 가기" 필드(320A)를 리뷰한다. 제어기(101)에 의해 리뷰된 이러한 정보에 기초하여, 제어기(101)는 자신의 현재 상태로부터 리소스 세트 "세트 1"로 제1 마스터 프로세서(110A)에 대한 현재 리소스 세트(304A)를 스위칭할 것이다. 리소스 세트 1은 제1 마스터 프로세서(110A)에 할당된 리소스 세트(304A)의 열(310A)에 열거된다.
또한, RPM(157) 또는 제어기(101)가 제1 트리거 세트의 클리어 열(324A1)에 예시된 것과 같은 "디코딩하지 않음" 이벤트를 검출할 때, 이후 제어기(101)는 이후 "세트로부터" 필드(318A)를 리뷰하고 이 값이 "세트 1"을 포함한다고 결정할 것이다. 제어기(101)는 이후 이 예에서 와일드카드 또는 별표의 값을 가지는 "세트로 가기" 필드(320)를 리뷰할 것이다. 이는 제어기(101)가 "세트 1" 리소스 세트로부터 프로세서(110A)에 의해 사용되는 마지막 활성 리소스 세트로 제1 마스터 프로세서(110A)의 리소스 세트(304A)를 스위칭할 것이다.
트리거 세트의 타이머 필드(326)는 특정 리소스 세트(304)가 제어기(101)에 의해 사용될 수 있는 시간량을 나타낼 수 있다. 따라서, 도 15를 예시하는 예시적인 실시예에 대해, 제1 트리거 세트의 타이머 필드(326A1)에 대해, 이러한 필드는 3 밀리초의 값을 가진다. 이는 디코드 인터럽트 이벤트가 제1 트리거 세트의 트리거 시작 필드(322A1)와 매치될 때, 이후 제어기(101)가 3 밀리초의 기간 동안만 "세트로 가기" 필드(320A)에 특정된 리소스 세트(304)를 활용함을 의미한다. 다른 예시적인 실시예들에서, 타이머 필드(326) 내에 어떠한 정보도 존재하지 않거나, 이러한 트랜지션을 위한 타이머 트리거(326)가 존재하지 않고 트랜지션이 오직 비 디코드 필드에만 적용함을 나타내는 값과 부합하도록 정의되는 상황들이 발생하거나 존재할 수 있다. 도 15에 예시된 바와 같은 타이머 필드 - 타이머 필드들(326A1 및 326A2) - 가 정의되는 상황에서, 이후 타이머 필드(326)와 클리어 필드(324) 사이에 어떤 이벤트가 먼저 발생하든 간에 일반적으로 트랜지션을 개시할 것이다.
도 16은 프로세서(110)에 대한 예시적인 활성-슬립 트리거 세트(314)를 예시한다. 이러한 예시적인 실시예에서, 제1 열(322) 내의 인터럽트 필드(316)는 특정 프로세서(110)에 대한 슬립 세트(308)(도 15)를 개시하기 위한 동작으로서 "셧 다운" 이벤트를 정의한다. "셧 다운" 이벤트는 운용자가 PCD(100)를 셧 다운하기 위한 온/오프 버튼을 선택하는 것과 같은 동작을 포함할 수 있다.
도 16의 예시적인 실시예에서, "셧 다운" 이벤트가 검출될 때, 제어기(101)는 현재 활성 리소스 세트(306)를 슬립 세트(308)로 트랜지션한다. 슬립 세트(308)는 도 15 내의 표(302)의 마스터 리소스 세트(304)에 열거되어 있다.
제어기(101)가 PCD(100)의 운용자에 의해 개시된 파워-온 이벤트와 같은 "띄우기: 이벤트가 발생했다는 메시지를 RPM(157)로부터 수신할 때, 이후 제어기는 트리거 세트(314)의 "세트로 가기" 필드(320)에 열거된 와일드카드 또는 별표에 기초하여 슬립 세트(308)로부터 마지막 활성 리소스 세트(304)로 프로세서를 트랜지션할 것이다.
전술된 바와 같이, 시스템(103)은 활성 및 슬립 세트들(306, 308)에 제한되지 않는다. 시스템(103)은 도 15에 예시된 바와 같이 슬립 상태들에 진입하거나 이탈하는 것이 아닌 이벤트들에 대해 리소스 세트들(304) 사이의 스위칭을 위해 사용될 수 있다.
도 17은 프로세서(110)를 슬립 상태로 두기 위해 트리거 세트들(314)을 관리하기 위한 방법(1700)을 예시하는 논리적 흐름도이다. 블록(1705)은 방법(1700)의 제1 단계이다. 블록(1705)에서, 각각의 프로세서(110)는 PCD(100)의 종래 사용 경우들로부터의 데이터에 기초하여 필요한 경우 제어기(101)(도 1-2)에서 프로세서(110)의 리소스 세트들(304) 뿐만 아니라 프로세서(110)의 트리거 세트들(314)을 업데이트할 수 있다.
블록(1710)에서, 프로세서(110)는 제어기(101)에 셧 다운 신호를 생성하도록 RPM(157)(도 14)에 요청할 수 있다. 블록(1715)에서 RPM(157)은 제어기(101)에 셧 다운 신호를 송신할 수 있다.
제어기(101)는 블록(1720)에서 셧 다운 신호를 수신하고, 도 16에 예시된 바와 같이 셧 다운 이벤트에 할당될 수 있는 트리거 세트들(314)을 활성화시킬 수 있다. 도 16에 예시된 예시적인 실시예에서, 셧 다운 신호는 트리거 세트(314)의 인터럽트 필드(316) 필드에 대해 매치된다. 트리거 세트(314)는 "세트로 가기" 필드(320)에서 표시된 바와 같이 슬립 세트(308)에 액세스하도록 제어기(101)에 지시한다. 블록(1725)에서, 제어기(101)는 제어기(101)가 셧 다운 신호 이벤트에 매치하는 트리거 세트들(314)에 의해 인용되는 리소스 세트들(304)을 계속 활성화시키는 동안 RPM(157)에 확인응답 신호를 즉시 송신할 수 있다.
블록(1730)에서, 도 16에 예시된 대응하는 인터럽트 필드(316) 내에 "셧 다운" 이벤트를 열거하는 매칭하는 트리거 세트(314)와 같은 각각의 매칭하는 트리거 세트(314)에 대해, 제어기(101)는 현재 리소스 세트(304)를 도 15의 마스터 프로세서(110A)에 대한 제1 리소스 세트(305A)의 슬립 세트(308A)와 같은 슬립 세트(308)로 스위칭할 수 있다.
다음으로, 블록(1735)에서, 제어기(101)는 도 14에 예시된 바와 같은 로우-레벨 드라이버들(103)로 슬립 요청 상태들을 발행할 수 있다. 로우-레벨 드라이버들(103)은 요청된 상태들을 대응하는 리소스들(105)로 전달할 수 있다.
블록(1740)에서, 각각의 리소스(105)는 제어기(101)와 RPM(157)에 셧 다운 신호 확인응답을 제어기(101)와 RPM(157)에 발행할 수 있다. 방법(1700)은 종료할 수 있다.
도 18은 프로세서(110)를 슬립 상태로부터 활성 상태로 두기 위해 트리거 세트들(314)을 관리하기 위한 방법(1800)을 예시하는 논리적 흐름도이다. 블록(1205)은 방법(1800) 내의 제1 단계이다. 블록(1805)에서, 웨이크-업 조건 또는 웨이크-업 이벤트는 RPM(157)을 이용하여 검출되거나, 또는 웨이크-업 이벤트는 자신의 고유한 인터럽트 제어기(예시되지 않음)를 가질 수 있는, 제어기(101)에 의해 직접 검출된다. 예시적인 실시예들은 웨이크-업 인터럽트들이 RPM(157)에 의해 검출가능하지 않을 수 있도록 설계될 수 있다. 이러한 예시적인 실시예들에서, 제어기(101)는 이들을 검출하기 위해 자신의 인터럽트 제어기를 사용하고, 마스터 프로세서(110)에 대한 슬립 세트 요건들에 이들을 "매핑"되게 할 수 있다.
다음으로, 블록(1810)에서, RPM(157)은 제어기(101)에 웨이크-업 신호를 송신할 수 있다. 블록(1815)에서, 제어기(101)는 RPM(157)로부터 웨이크-업 신호를 수신하고, 웨이크-업 신호를 매치시킨 하나 이상의 트리거 세트들(314)을 활성화시킬 수 있다. 예를 들어, 제어기(101)는 도 16의 트리거 세트(314)의 "활성" 열에서의 인터럽트 필드(316)에 열거된 "띄우기" 이벤트와 웨이크-업 신호를 매치시킬 수 있다. 도 16의 예시적인 실시예에서, 활성 열(324) 내의 "가기 필드"(320)는 현재 프로세서(110)에 의해 사용된 마지막 리소스 세트(304)에 제어기를 전달한다.
따라서, 블록(1820)에서, 제어기(101)는 이러한 매칭하는 트리거 세트(314)에 기초하여 프로세서(110)에 대해 현재 리소스 세트(304)를 변경시킬 것이다. 당업자는 제어기(101)가 도 15에 예시된 바와 같이 제어기가 보유하고 있는 자신의 모든 트리서 세트들을 통해 순환할 것임을 인식할 것이다.
다음으로, 블록(1825)에서, 제어기(101)는 어느 마스터 프로세서들(110)이 슬립 상태로부터 깨어났는지를 식별하는 웨이크-업 확인응답을 RPM(157)에 송신할 수 있다. 다음으로, 블록(1830)에서, 매칭하는 웨이크 업 트리거 세트(314)를 가지는 각각의 프로세서(110)가 슬립 상태로부터 릴리즈되어 RPM(157)에 의해 공급되는 전력을 가지고 자신의 활성 상태로 복원된다. 방법(1800)은 이후 종료한다.
도 19-20은 "다음-활성 리소스 상태 세트" 또는 "다음-활성 세트"로서 이 설명에서 지칭되는 또다른 특징을 예시한다. 다음-활성 세트의 일 예는 다음-어웨이크 세트이다. 다음-어웨이크 세트 또는 다른 다음-활성 세트는 도 18 및 제어기(101)가 웨이크-업 이벤트에서 스위칭하는 리소스 세트(304)에 관해 전술된 동일한 방식으로 사용될 수 있다.
도 19는 제어기(101)에 저장된 정보를 나타낸다는 점에 있어서 도 15와 유사하다. 예시적인 실시에에서, 제어기(101)는 이 설명에서 편의상 "A" 메모리 버퍼(702), "B" 메모리 버퍼(704), 및 "C" 메모리 버퍼(706)로 지칭되는 3개의 메모리 버퍼들을 포함할 수 있다.
도 20은 프로세서를 슬립 상태로 두기 위한 방법(800)을 예시한다는 점에 있어서 도 17과 유사한 논리적 흐름도이다. 블록(2005)은 방법(800)의 제1 단계이고 도 17과 관련하여 전술된 블록(1705)과 유사하다. 블록(2005)은 프로세서(110)가 활성 또는 어웨이크 리소스 상태 세트 및 슬립 리소스 상태 세트 뿐만 아니라 다음-어웨이크 리소스 상태 세트를 업데이트 할 수 있음을 나타낸다. 도 20에 도시된 바와 같이, 프로세서는 활성 세트가 제어기(101)의 "A" 버퍼(702)(도 19)에 저장되도록 하고, 슬립 세트가 제어기(101)의 "B" 버퍼(704)(도 19)에 저장되게 하고, 다음-어웨이크 세트가 제어기(101)의 "C" 버퍼(706)(도 19)에 저장되게 할 수 있다. 블록(2005)의 다른 양상들은 블록(1705)에 관해 전술된 것과 동일하며, 따라서 여기서 설명되지 않는다.
블록들(2010, 2015, 2020, 2025, 2030, 2035 및 2040)은 각각 도 17의 블록들(1710, 1715, 1720, 1725, 1730, 1735 및 1740)과 동일하며, 따라서, 여기서 설명되지 않는다. 프로세서가 셧 다운되기 시작할 때, 프로세서가 "A" 버퍼(702)(도 19)에 저장된 어웨이크 세트에 대응하는 어웨이크 애플리케이션 상태에 있다는 점에 유의한다. 프로세서는 이후, 도 17에 관해 전술된 것과 동일한 방식으로 "B" 버퍼(704)(도 19)에 저장된 슬립 세트에 대응하는 슬립 애플리케이션 상태에 진입한다. 프로세서는 슬립 애플리케이션 상태로부터 "C" 버퍼(706)(도 19)에 저장된 다음-어웨이크 세트에 대응하는 다음-어웨이크 애플리케이션 상태에서 깨어난다(도 18). "C" 버퍼(706)에 다음-어웨이크 세트 업데이트들을 사전-저장하고, 이들을 가능한 빨리 인가함으로써, 제어기(101)는 웨이크-업 이벤트 시에 상기 다음-어웨이크 세트에 의해 특정된 리소스들을 즉시 구성하기 시작하고, 이에 의해 리소스 레이턴시를 최소화하는 것을 보조할 수 있다.
도 21은 노드 스케쥴러(2101), 리소스 전력 매니저("RPM")(157)와 다른 노드 아키텍쳐 시스템 엘리먼트들 간의 관계들을 예시하는 기능 블록도이다. 구체적으로, 스케쥴러(2102)는 스케쥴러 데이터베이스(2103); 리소스 전력 매니저(157); CBM(CPU busy monitor) 리소스(2109); 슬립 저-전력 리소스(2107); 타이머(2105); 도 3의 프레임워크 매니저(440); 및 다양한 리소스들(105A-N)에 커플링된다. RPM(157)은 도 14-15와 관련하여 전술되었다. RPM(157)은 PCD(100)의 다양한 프로세서들(110)의 상태들을 유지하기 위해 활성 및 슬립 세트들을 포함하는 리소스 세트들(304)을 유지하고 모니터링하기 위한 제어기(101)(도 15를 참조)와 함께 작용한다.
리소스들(105A-105N)은 도 3-6 및 14-16과 관련하여 전술된다. 리소스들(105)은 하드웨어 및/또는 소프트웨어를 포함할 수 있다. 리소스들(105)은 스케쥴러(2101)에 의해 관리되는 요청들(675)을 수신할 수 있다.
스케쥴러(2101)는 도 3과 관련하여 전술된 바와 같은 프레임워크의 일부분이다. 스케쥴러(2101)는 프레임워크 매니저(440)에 커플링된다. 스케쥴러(2101)는 리소스(105)를 목적지로 하는 클라이언트(648)에 의해 발행된 요청(675)(프레임워크 매니저(440)와 관련하여 전술된 클라이언트들(648) 및 요청들(675)에 대한 상세항목들을 예시하는 도 3-5를 참조하라)이 언제 요청에서 특정된 타이밍 데드라인에 기초하여 적용될 것인지를 특정하는 큐잉 특징을 제공한다. 스케쥴러(2101)에 대한 타이밍은 타이머(2105)에 의해 트래핑된다.
스케쥴링된 요청(675)이 클라이언트(648)에 의해 이루어진 이후, 호출 애플리케이션 또는 엔티티는 이후 자신만의 프로세싱을 계속할 수 있다. 스케쥴러(2101)는 이후 클라이언트(648)에 의해 제공되는 데드라인에 기초하여 요청(675)을 실행하기 위한 최상의 방식을 결정할 것이다.
스케쥴러(2101)는 각각의 스케쥴링된 요청(675)을 보고, 스케쥴링된 요청(675)이 실행하는데 얼마나 오래 걸릴지를 결정한다. 스케쥴러(2101)는 또한 백-오프 계산들을 수행한다. 스케쥴러(2101)는 타이머(2105)와 그리고/또는 어떤 스케쥴링된 요청들(675)이 적용될지 그리고 이들이 클라이언트(648) 또는 호출 엔티티에 의해 특정된 바와 같이 요청된 데드라인을 만족시키기 위해 언제 발생해야 하는지를 이해하기 위해 프로세서(110)의 슬립 사이클을 가지고 작용한다.
당업자에 의해 이해되는 바와 같이, 타이머(2105)는 T 틱(tick) 시간에서 실행하는 32-비트 타이머를 포함하는 클록을 포함할 수 있다. 다른 클록들이 이 개시내용으로부터의 이탈 없이 사용될 수 있다. 예를 들어, 당업자에 의해 이해되는 바와 같이, 64-비트 타이머 시스템들이 사용될 수 있다. 32-비트 타이머들에 대해, 스케쥴러(2101)는 타이머(2105)에 의해 트래킹되는 현재 시간과 스케쥴링된 요청(675)에서 특정된 요청된 시간 사이의 차이를 봄으로써 요청(675)에 대한 시간이 과거 또는 미래에 있는지를 결정할 수 있다.
32-비트 타이머 시스템을 통해 늦은 요청(675) 대 먼 미래의 요청을 검출하기 위해, 원하는 시간은 차이가 UINT_MAX (0 X 8000 0000)보다 더 작은 경우 시간의 분해능의 절반 미만이어야 하며, 이후 그것은 미래에 있는 것으로 스케쥴러(2101)에 의해 고려된다. 요청된 시간이 UINT_MAX보다 더 크거나 같은 경우, 요청된 시간은 스케쥴러(2101)에 의해 과거에 발생한 것으로 고려되고, 스케쥴러(101)는 일반적으로 이러한 요청(675)을 즉시 프로세싱한다.
스케쥴러(2101)에 의해 결정된 전술된 타이밍들은 스케쥴러 데이터베이스(2103)에 스케쥴러(2101)에 의해 저장된다. 스케쥴러 데이터베이스(2103)는 요청들(675)이 수행될 수 있는 다양한 방식들에 관련될 수 있는 정보, 및 요청들이 특정 시퀀스들에서 발생할 때 요청들(675)에 대해 요구되는 각자의 타이밍을 보유한다. 다시 말해, 스케쥴러(2101)는 스케쥴러(2101)가 상이한 시나리오들에 따라 요청들(675)을 서비스하고 이들 값들을 스케쥴러 데이터베이스(2103)에 저장하는데 걸릴 수 있는 각자의 시간들과 다양한 옵션들을 트래킹할 수 있다. 스케쥴러 데이터베이스(2103)에 관한 추가적인 상세항목들은 도 22와 관련하여 하기에 설명될 것이다.
슬립 저전력 리소스("LPR")(2107)는 시스템(100)이 데이터베이스(2103)를 리뷰함으로써 슬립 상태로부터 깨어날 때 어느 리소스들(105)이 트리거링될 필요가 있는지를 결정한다. 슬립 LPR(2107)은 API(application programming interface)로서 특성화될 수 있다. 슬립 LPR(2107)은 슬립 LPR(2107)이 제어기(101)와 RPM(157)에 의해 관리되는 리소스 세트(304)의 다음 어웨이크 세트에 존재한다고 결정하는 해당 요청들(675)을 발행할 것이다.
CBM(CPU busy monitor) 리소스(2109)는 스케쥴러(2101)에 의해 설정된다. CBM 리소스(21000)는 스케쥴러(675)에 의해 관리되는 요청들(675)을 서비스하는 모든 CPU들(110)의 상태들을 트래킹한다. CBM 리소스(2109)에 대한 임의의 넌제로 요청들(675)은 요청(675)을 발행하는 클라이언트(648) 또는 사용자 스레드(2301)(도 23 참조)가 CPU(110)가 요청(675)의 실행 동안 비지(busy) 상태를 유지하는 것을 예상한다. CBM 리소스(2109)는 CPU(110)가 임의의 클라이언트(648)가 비지 상태인 한 CBM 리소스(2109)에 의해 비상태로 간주되는 것을 의미하는 바이너리 리소스이고, CPU(110)는 마지막 클라이언트(675)가 넌제로 또는 비지 요청을 완료할 때까지 자유롭거나 비지상태가 아닌 것으로서 특성화되지 않는다. 스케쥴러(2101)와 CBM 리소스(2109) 사이의 동작과 관계에 관한 추가적인 상세항목들은 도 29와 관련하여 하기에 설명될 것이다.
도 22는 스케쥴러 데이터베이스(2103)의 예시적인 콘텐츠를 예시하는 다이어그램이다. 도 21과 관련하여 전술된 바와 같이, 스케쥴러 데이터베이스(2103)는 요청들(675)이 수행될 수 있는 다양한 방식들에 관련될 수 있는 정보, 및 요청들(675)이 특정 시퀀스들에서 발행할 때 요청들(675)에 대해 요구되는 각자의 타이밍을 보유한다. 다시 말해, 스케쥴러(2101)는 스케쥴러(2101)가 상이한 시나리오에 따라 요청들(675)을 서비스하고 이들 값들을 스케쥴러 데이터베이스(2103)에 저장하는데 걸릴 수 있는 각자의 시간들 및 다양한 옵션들을 트래킹할 수 있다.
스케쥴러 데이터베이스(2103)는 후속하는 정보, 즉 스레드 구성 데이터(2205); 스케쥴러 레이턴시(2210); 최소 스케쥴러 델타(2215); 요청 레이턴시(2220); 포크 룩-어헤드 델타(2225); 포크 레이턴시(2230); 조인(join) 레이턴시(2235); 슬립 웨이크 트랜지션 레이턴시(2245); 시간 큐 레이턴시; LPR(low power resource) 진입 레이턴시(2250); LPR 이탈 레이턴시(2255); LPR 현재 델타(2260); 스케쥴링된 링크된 리스트들(2270); 요청 상태들(2275); 요청 시간들(2280); 시작 시간들(2285); 늦을 확률(2287); 회신 통지들(2290); 가장 최근의 통지 상태들(2293); 및 요청 지연도(2295)를 포함할 수 있지만 이에 제한되지 않는다.
스레드 구성 데이터(2205)는 클라이언트들(648)과 요청들(675)을 발신하는 스레드들로부터의 다양한 정보를 트래킹할 수 있다. 스케쥴러 레이턴시(2210)는 타이머(2105)에 의해 측정된 틱 단위의(in ticks) 스케쥴러 코드를 핸들링하는데 걸리는 시간을 측정할 수 있다. 최소 스케쥴러 델타(2215)는 현재 타임아웃에 의해 미래에 핸들링되기에는 너무 멀기 때문에 요청들(675)이 재스케쥴링될 시간을 측정할 수 있다.
요청 레이턴시(2220)는 스케쥴링된 요청들(675)이 리소스(105) 상에서 발행되는 경우 사용되는 디폴트 스케쥴링된 요청 레이턴시를 측정할 수 있다. 요청 레이턴시(2220)는 완료를 위해 완전히 비동기식인 요청(675)을 발행하는 것으로부터 예상되는 시간을 포함할 수 있다. 포크 룩-어헤드 델타(2225)는 어느 요청들(675)이 분기되기에(forked) 적절할 수 있는지를 결정하는 슬립 웨이크 시간에 더할 시간을 측정할 수 있다. 이러한 델타(2225)는 슬립 세트가 슬립 상태로부터 깨어날 때 수행해야 할 수 있는 작업을 보상하기 위해 사용될 수 있다.
포크 레이턴시(2230)는 스케쥴링된 요청이 리소스(105) 상에서 발행되지만 리소스(105)가 포크 요청 레이턴시 질의를 지원하지 않는 경우 사용될 수 있는 디폴트 스케쥴링된 포크 레이턴시이다. 포크 레이턴시(2230)는 분기된 요청(675)이 되돌아갈 때 분기된 요청(675)을 발행하는 것으로부터의 시간을 포함한다. 포크 레이턴시(2230)에 대한 요청은 분기가능한 리소스(105)에 대해서만 유효하다.
조인(join) 레이턴시는 리소스(105)가 조인되고 분기된 요청이 중단(retired)될 때까지 포크 동작이 완료할 때의 시간을 포함할 수 있다. 조인 레이턴시(2235)는 또한 스케쥴링된 요청(675)이 리소스(105) 상에서 발행되지만 리소스(105)가 조인 레이턴시 질의를 지원하지 않는 경우 사용될 수 있는 디폴트 스케쥴링된 포크 레이턴시이다.
슬립 웨이크 트랜지션 레이턴시(2240)는 슬립 세트가 슬립 상태를 이탈하는데 걸리는 시간, 타이머(2105)가 시작하는데 필요한 시간, 및 다수의 요청들(675)이 조인될 때 요구되는 임의의 시간을 측정한다. 시간 큐 레이턴시(2245)는 타이머(2105)가 타이머 기능을 호출하는데 걸리는 시간을 측정할 수 있다.
LPR(low power resource) 진입 레이턴시(2250)는 LPR 진입 기능을 사용할 때 오버헤드에 대한 디폴트 시간을 포함할 수 있다. LPR 이탈 레이턴시(2255)는 LPR 이탈 기능을 사용할 때 오버헤드에 대한 디폴트 시간을 포함할 수 있다. LPR 현재 델타(2260)는 LPR 진입 기능이 타이머(2105)를 재스캐쥴링하기 위한 디폴트 시간을 포함할 수 있다.
스케쥴러 데이터베이스(2103)의 나머지 데이터는 도 22에서 예시된 바와 같이 요청 정의들(2265)로서 특성화될 수 있다. 스케쥴링된 링크된 리스트(2270)는 실행하도록 대기하고 있는 클라이언트들(648)을 트래킹할 수 있다. 요청 상태(2275)는 요청 시간(2280)이 요청들(675)이 완료되어야 하는 시간을 포함할 수 있는 대기, 프로세싱, 분기됨, 조인됨 등과 같은 다양한 요청들(675)의 상태들을 트래킹할 수 있다. 시작 시간(2285)은 클라이언트(648)로부터 발행된 요청들(675)을 시작하기 위해 요구되는 시간을 트래킹할 수 있다.
늦을 확률 파라미터(2287)는 스케쥴러(2101)가 요청들(675)을 스케쥴링하는 시간일 때 스케쥴러(2101)에 유연성을 제공한다. 늦을 확률 파라미터(2287)가 0과 같도록 세팅되는 경우, 이것은, 요청(675)이 스케쥴러(2101)에 의한 요청의 스케쥴링에 대한 어떠한 지연도도 허용하지 않을 수 있음을 의미한다. 늦을 확률 파라미터(2287)가 1과 같도록 세팅되는 경우, 스케쥴러(2101)는 이러한 지연도가 스케쥴러(2101)가 자신의 요청들(675)의 현재 세트를 프로세싱하도록 보조할 경우 요청(675)이 늦는 것을 허용할 수 있다. 스케쥴러(2101)는 또한 지연도의 허용되는 레이트로서 0과 1 사이의 값들을 트래킹할 수 있다. 따라서, 0과 1 사이의 값은 클라이언트가 요청이 늦는 것의 절반을 허용하도록 세팅될 수 있다. 0과 1 사이의 또다른 값은 모든 요청들이 늦는 것이 허용될 수 있도록 세팅될 수 있는 등의 식이다.
회신 통지(2290)는 요청(675)을 발행한 클라이언트(648)에 대한 회신이 언제 완료되는지를 트래킹한다. 가장 늦은 통지 상태(2293)는 회신 통지들이 제시간에 발행되었는지; 늦게 발행되었는지; 또는 요청이 재스케쥴링되었는지를 트래킹한다. 그리고 요청 지연도(2295)는 요청들(675)이 늦지 않을 때의 시간들, 요청(675)이 늦을 때의 시간들, 및/또는 늦은 요청(675)이 종료되었을 때와 늦은 요청(675)이 요청되었을 때 사이의 시간의 합산을 트래킹할 수 있다. 스케쥴러 데이터베이스(2103)는 이들 파라미터들에 제한되지 않는다. 당업자에 의해 이해될 바와 같이, 다른 파라미터들이 스케쥴러 데이터베이스(2103)에 의해 트래킹될 수 있다.
이제 도 23을 참조하면, 이 도면은 클라이언트들(648), 클라이언트 요청들(675), 스케쥴러(2101)와 타이머(2105) 사이의 관계들을 보여주는 예시적인 타이밍도(2300)를 예시한다. 도 23의 Y-축은 시간에 부합한다. 클라이언트들(648)과 요청들(675)의 베이스라인 논의에 대해서는 도 3-6의 이전 논의를 참조하라.
사용자 스레드(2301)에 의해 설정된 클라이언트(648)는 시간 X의 특정 요청된 데드라인에서 발행할 리소스(105)(예시되지 않음)에 대한 스케쥴링된 요청(675)을 수행하기를 원한다. 사용자 스레드(2301)는 클라이언트(648)가 프레임워크(300) 내에서 생성된 이후 요청(675)을 발행한다.
요청(675)은 벡터 요청, 스칼라 요청, 또는 이전에 설명된 바와 같은 임의의 다른 표준 동기식 요청과 같은, 그러나 이에 제한되지 않는, 임의의 타입의 요청을 포함할 수 있다. 스케쥴러(2101)는 요청(675)으로부터의 정보를 데이터베이스(2103)에 배치한다. 요청(675)으로부터의 정보는 데이터베이스(2103)와 관련하여 도 22에서 전술된 정보를 포함할 수 있지만, 이에 제한되지 않는다.
구체적으로, 스케쥴러(2101)는 모든 요청들(675)이 각자의 데드라인들에 의해 종료하거나 실행되도록 각각의 요청(675)이 언제 실행되어야 하는지를 결정한다. 스케쥴러(2101)는 또한 각각의 요청(675)에 대한 백오프를 계산할 수 있다. 스케쥴러(2101)는 데이터베이스(2103)에서 이 정보를 유지한다. 이전에 설명된 바와 같이, 데이터베이스(2103)는 요청들(675)이 수행될 수 있는 다양한 방식들에 관련될 수 있는 정보, 및 요청들(675)이 특정 시퀀스들에서 발행할 때 요청들(675)에 대해 요구되는 각자의 타이밍을 보유한다. 다시 말해, 스케쥴러(2101)는 스케쥴러(2101)가 상이한 시나리오들에 따라 요청들(675)을 서비스하고 이들 값들을 스케쥴러 데이터베이스(2103)에 저장하는데 걸릴 수 있는 각자의 시간과 다양한 옵션들을 트래킹할 수 있다.
추후, 클라이언트 블록(675)에서, 사용자 스레드(2301) 또는 요청 엔티티는 다른 데이터 또는 기능들에 대한 자신만의 고유한 프로세싱을 계속할 수 있다. 스케쥴러(2101)는 하나 이상의 리소스들(105)이 하나 이상의 요청들(675)을 프로세싱하기 위해 깨어나야 하는 시간을 결정하고, 이후 스케쥴러(2101)는 스테이지(2305A)에서 타이머(2015)에 대해 타이밍 커맨드를 발행한다.
스테이지(2310)에서, 타이머(2015)는 만료하거나 또는 스케쥴러(2101)에 의해 특정된 시간에 다다르고, 스케쥴러(2101)에 대해 신호를 발행한다. 스테이지(2310)에서, 스케쥴러(2101)는 데이터베이스(2103)에 질의하고, 스케쥴러(2101)가 프로세싱할 필요가 있는 하나 이상의 요청들(675)을 결정한다. 스케쥴러(2101)가 특정 스테이지(2310)에 대해 데이터베이스(2103)에 열거된 요청들(675)을 실행하는 동안, 스케쥴러(2101)는 요청들(675)이 제시간에 프로세싱되는지 또는 요청들(675)이 늦게 실행되는지를 측정하고 트래킹한다. 스케쥴러(2101)는 이 스테이지(2310)에서 또한 이들의 완료를 위해 요청들(675)의 각자의 지속기간들을 결정하고, 이 정보를 데이터베이스(2103)에 레코딩한다.
스케쥴러(2101)는 스테이지(2310)에서 또한 특정 요청들(675)의 프로세싱 또는 실행을 지연시키도록 결정할 수 있고, 스케쥴러(2101)는 이후 타이머(2105)에 추가적인 타이밍 커맨드들("셋업이 요구되는 타이머 이벤트")을 발행할 수 있고, 따라서 데이터베이스(2103)에 열거된 바와 같은 이들 다른 요청들(675)은 추후 시간에 발생할 수 있다.
스케쥴러(2101)는 심지어 스케쥴러(2101)가 사용자 스레드(2301 145)에 따라 클라이언트(648)에 의해 특정된 바와 같이 이들의 요청된 데드라인들보다 더 늦게 특정 요청들(675)을 실행할 필요가 있는 경우라도 데이터베이스(2103) 내의 모든 요청들(675)을 받아들이고(honor) 실행하려고 시도할 것이다.
스케쥴러(2101)가 리소스(105)가 요청(675A)을 완료했다고 결정할 때, 스케쥴러(2101)는 클라이언트 통지 또는 회신(2315A)을 생성한다. 이러한 클라이언트 통지(2315A)에서, 스케쥴러(2101)는 요청(675A)이 제시간에(요청된 데드라인까지) 수행되었는지 또는 요청(675A)이 요청된 데드라인보다 더 늦게 수행되었는지를 클라이언트(648)에 통지할 것이다.
각각의 요청(675)은 또한 도 22와 관련하여 전술된 바와 같이, 지연도(2287)의 확률과 같은 추가 정보를 포함할 수 있다. 이러한 지연도의 확률 파라미터(2287)는 스케쥴러(2101)가 요청들(675)을 스케쥴링할 시간일 때 스케쥴러(2101)에 유연성을 제공할 수 있다.
지연도의 확률 파라미터(2287)가 0과 같도록 세팅되는 경우, 이는, 요청(675)이 스케쥴러(2101)에 의한 자신의 스케쥴링에 대한 어떠한 지연도도 허용하지 않을 것임을 의미한다. 한편, 지연도의 확률 파라미터(2287)가 Oxffff ffff 중 0x8000 0000(50 퍼센트)와 같도록 세팅되는 경우, 이는, 요청(675)이 스케쥴러(2101)에 의해 프로세싱되는 100번(1 퍼센트) 중 50번의 지연도를 요청(675)이 허용할 수 있음을 의미한다. 지연도의 확률 파라미터(2287)는 스케쥴러(2101)가 일부 유연성을 가지고 요청들(675)을 스케쥴링하게 한다.
예를 들어, 요청(675)이 리소스(105)에 의해 완료되기에 적어도 10 밀리초(ms)가 걸릴 수 있다고 가정한다. 일부 상황들에서, 요청(675)은 시간의 리소스(105) 99퍼센트에 의해 완료되는데 오직 1ms만 걸릴 수 있다. 이 요청(675)에 대한 지연도의 확률 파라미터가 0과 같도록 세팅되는 경우, 스케쥴러(2101)는 요청(675)이 제시간에 완료되도록 요청된 데드라인으로부터 적어도 10초 떨어지도록이 요청을 스케쥴링해야 한다.
그러나, 지연도의 확률 파라미터(2287)가 0x2900000(1퍼센트를 의미함)와 같도록 세팅되는 경우, 스케쥴러(2101)는 임의로, 요청(675)의 지속기간이 오직 1m초만 지속되는 경우 요청(675)이 제시간에 완료될 수 있도록, 요청된 데드라인으로부터 1초만큼 떨어져서 이 요청(675)을 스케쥴링할 수 있다. 그러나, 요청(675)은, 전술된 최악-경우의 10ms와 같이, 요청의 지속기간이 1ms를 초과하는 경우, 요청된 데드라인보다 훨씬 더 늦게 종료할 수 있다.
데이터베이스(2103)는 또한 각각의 요청(675)에 대한 최악-경우의 값을 보유할 수 있다. 최악-경우의 값은 통상적으로, 요청(675)이 특정된 데드라인까지 완료되도록 요청 시작 시간(2285)(도 22와 관련하여 위에서 논의된 데이터베이스 파라미터를 참조하라)의 가장 보존적인 추정을 포함한다. 위에서 주지된 바와 같이, 각각의 요청(675)은 사용자 스레드(2301)를 통해 클라이언트(648)에 의해 특정된 데드라인을 가진다. 디폴트로서, 지연도의 확률 파라미터(2287)가 특정되지 않거나, 요청(675) 내의 값을 제공받지 않는 경우, 스케쥴러(101)는 요청(675)에 대한 최악-경우의 값을 항상 사용할 것이다.
이제 도 24를 참조하면, 이 도면은 클라이언트들(648), 클라이언트 요청들(675), 스케쥴러(2101), 타이머(2105)와, 슬립 세트들을 트래킹하는 제어기(101) 간의 관계들을 보여주는 예시적인 타이밍도(2400)를 예시한다. 도 24의 Y-축은 시간에 부합한다. 클라이언트들(648) 및 요청들(675)의 설명에 대해서는 도 3-6의 이전 논의를 참고하라. 또한, 이전에 전술된 바와 같이 슬립 세트들을 트래킹하는 제어기(101)의 추가적인 상세항목들을 예시하는 도 15를 참고하라.
클라이언트(648)는, 사용자 스레드(2301)를 통해, 리소스(105)(예시되지 않음)에 대한 요청(675)을 수행하기를 원한다. 클라이언트(648)는 특정된 시간에서 요청(675)이 발생하기를 원한다. 요청(675)은 벡터 요청, 스칼라 요청, 또는 임의의 다른 표준 동기식 요청과 같은, 그러나 이에 제한되지 않는 임의의 타입의 요청(198)을 포함할 수 있다.
스케쥴러(2101)는 요청(675)으로부터의 정보를 데이터베이스(2103)에 둔다. 위에서 주지된 바와 같이, 스케쥴러(2101)는 모든 제출된 요청들(675)이 각자의 데드라인까지 종료하거나 실행되도록 각각의 요청(675)이 언제 실행되어야 하는지를 계산한다. 스케쥴러(2101)는 이 스테이지에서 백오프를 계산한다.
추후, 요청 블록(675)에서, 사용자 스레드(2301) 또는 요청 엔티티는 다른 데이터 또는 기능들에 대한 자신의 고유한 프로세싱을 계속할 수 있다. 스케쥴러(2101)는 하나 이상의 리소스들(105)(예시되지 않음)이 요청(675)을 프로세싱하도록 깨어나야 하는 시간을 결정하고, 이후 스케쥴러(101)는 스테이지(2305A)에서 타이머(860)에 타이밍 커맨드를 발행한다.
슬립 이벤트는 스테이지(2427)에서 발생하도록 스케쥴링된다. 스테이지(2410)에서, 제어기(101)(또는 제어기(101)의 리소스 스테이지들(304)을 리뷰하는 스케쥴러(2101))는 스테이지(2427)에서 슬립 이벤트 또는 슬립 사이클의 지속가간 및 스테이지(2430)에서 예상되는 웨이크-업 시간을 데이터베이스(2103)에 저장한다. 스테이지(2415)에서, 스케쥴러(2101)는, 스테이지(2427)에서 슬립 사이클이 일단 종료하면 RPM(resource power manager)(157)이 어느 어웨이크 세트가 사용되어야 하는지를 알게 되도록 RPM(156)에 리소스 세트(304)(도 15)의 다음 어웨이크 세트를 통신할 수 있다.
스케쥴러(2101)는 리소스 세트(304)의 다음 어웨이크 세트의 일부분에 대해 이제 이루어져야 하는 하나 이상의 요청들(675)을 포함할 수 있고, 따라서 이들 요청들(675)은 시스템이 스테이지(2430)에서 슬립 상태를 빠져나올 때 실행된다. 다음 어웨이크 세트들이 RPM(157)에 통신된 스테이지(2415)에서의 RPM 통신 이후, 스테이지(2420)에서, 스케쥴러(2101)는 커맨드 "핸들 요청"(675)을 발행한다. 커맨드 핸들 요청(675)은 RPM(157)이 이 스테이지에서 임의의 후속적인 요청들(675)을 포함하여 제어기(101)에 의해 관리되는 리소스 세트(304)의 다음 어웨이크 세트의 일부분이 되게 한다.
이전에 주지된 바와 같이, 데이터베이스(2103)는, 하이 레벨에서, 클라이언트들(648), 리소스들(105), 및 요청들(675)을 트래킹한다. 데이터베이스(2103)는 또한 요청(675)의 일부분인 요청된 데드라인을 트래킹할 수 있다.
데이터베이스(2103)는 또한 각각의 요청(675)이 완료될 필요가 있는 시간, 각각의 요청(675)이 시작될 필요가 있는 시간, 각각의 요청(675)에 대한 종료 시간, 요청(675)을 실행하기 위한 지속기간, 발신 클라이언트 또는 사용자 스레드(2301)에 통지 또는 회신을 수행할 필요가 있는 지속기간, 모든 핸들링의 지속기간, 및 요청(675)이 실행되기 전의 임의의 타이머들(2015)의 지속기간을 포함하는 스케쥴러(2101)에 의해 이루어진 계산들을 보유할 수 있다.
다수의 요청들(675)이 존재하는 경우, 데이터베이스(2103)는 다수의 요청들(675)과 오버랩으로 인한 시간 상의 임의의 시프팅 사이에 발생할 수 있는 시간 상의 임의의 오버랩에 대해 스케쥴러(2101)에 의해 이루어진 계산들을 트래킹한다. 구체적으로, 위에서 언급된 하이-레벨 데이터는 전술된 도 22에서 열거된 바와 같은 정보에 의해 트래킹될 수 있다.
리소스(105)는 상기 리소스(105) 또는 또다른 리소스(105)에 의한 실행을 위해, 또한 레이턴시라고 지칭되는, 특정 요청들(675)이 얼마나 오래 걸릴 수 있는지에 대한 정보를 데이터베이스(2103)에 제공할 수 있다. 스케쥴러(101)는 도 22와 관련하여 전술된 바와 같이 적어도 3가지 타입의 레이턴시 데이터, 즉, 요청 레이턴시(2220), 포크 레이턴시(2230), 및 조인 레이턴시(2235)에 대해 리소스(105)에 질의할 수 있다. 리소스(105)가 임의의 레이턴시에 대한 값을 제공하지 않는 경우, 리소스의 디폴트 값들이 사용될 것이다.
리소스(105)가 다소 직접적으로 요청(675)을 핸들링하며, 스케쥴러(2101)가 관련되지 않게 하는 경우, 리소스(105)는 스케쥴러(2101)로부터의 요청 레이턴시 커맨드에 응답하여 0의 레이턴시 값을 되돌릴 수 있다. 레이턴시에 대해 이러한 0의 값을 수신할 때, 스케쥴러(2101)는 이후 리소스(105)가 요청(675)을 직접 핸들링하도록 요청(675)의 핸들링을 포기(drop)할 수 있다.
리소스(105)는 스케쥴러(2101)로부터 레이턴시 요청에서 요청된 것을 넘어 추가적인 정보를 제공할 수 있다. 예를 들어, 리소스(105)는 리소스가 리소스(105)에 의해 서비스될 실제 요청(사용자 스레드(2301)를 통해 클라이언트(648)에 의해 발행됨)에 대해 적어도 2개의 동작 모드들을 지원함을 스케쥴러(2101)에 통지할 수 있다. 리소스(105)는 스케쥴러(2101)에 2개의 동작 모드들 각각에 대한 레이턴시에 대한 데이터를 제공할 수 있다.
스테이지(2427)에서 슬립 상태 바로 이전에 스테이지(2425)에서, 스케쥴러(2101)는 슬립 상태를 핸들링하는 제어기(101)를 통해 슬립 스케쥴러 LPR(low-power resource)(2107)를 호출할 것이다. 슬립 LPR(2107)는 시스템이 데이터베이스(2103)를 리뷰함으로써 스테이지(2427)에서 슬립 상태로부터 깨어날 때 어느 리소스들(105)이 트리거링될 필요가 있는지를 결정한다. 슬립 LPR(2107)는 API(application programming interface)로서 특성화될 수 있다.
슬립 LPR(2107)는 슬립 LPR(2107)이 제어기(101)에 의해 관리되는 리소스 세트(304)의 다음 어웨이크 세트에서 존재할 것으로 결정하는 요청들(675)을 발행할 것이다. 이 스테이지에서, 슬립 LPR(2107)이, 프로세서(110)를 포함하는 시스템이 스테이지(2430)에서 슬립 상태로부터 이탈할 때 프로세싱될 필요가 있는 요청들(675)을 사전 계획하고 있기 때문에, 엄청난 에너지 절감이 달성될 수 있다.
구체적으로, 스테이지(2425)에서 슬립 상태 바로 이전에, 슬립 LPR(2107)는 스테이지(2430)에서 슬립 상태를 이탈할 시에 향상되고 프로세싱될 수 있으며 리소스 세트(304)의 다음 어웨이크 세트에 배치될 수 있는 요청들(675)을 어느 리소스들(105)이 스케쥴링하는지를 식별할 것이다.
요청들(675)은 분기가능한 요청들(675)로서 발행될 것이고, 슬립 LPR(2107)은 이후 스케쥴러(2101)가 조인 기능들을 수행하기 위한 새로운 데드라인을 제어기(101)와 스케쥴러(2101)에 통지할 것이다. 스테이지(2427)에서의 슬립 상태는 정상적으로 진행할 수 있다. 시스템 또는 프로세서(110)가 스테이지(2430)에서 깨어날 때, RPM(157)은 조인을 시그널링하고, LPR의 이탈 기능은 스케쥴러(2101)가 요청들(675)에 조인하도록 시그널링할 것이다. 슬립 상태가 스테이지(2430)에서 이탈할 때, 스케쥴러(2101)는 리소스(105)의 사용 이전에 요구되는 임의의 최종 작업을 완료하고, 이후 스케쥴링된 클라이언트의 완료 회신 또는 클라이언트 통지(2315A)를 불러올 수 있다.
도 25는 하나 이상의 사용자 스레드들(2301)이 스케쥴러(2101)를 호출함으로써 블록들(1205A, 1205B)에서 2개의 요청들(675)을 생성할 때 예시적인 시나리오를 예시한다. 요청들(675)의 생성에 대해서는 전술된 도 12를 참고하라.
제1 요청은 제1 클라이언트(648A)로서 블록(1205A)에서 생성되는 반면, 제2 요청은 제2 클라이언트(648B)로서 블록(1205B)에서 생성된다. 사용자 스레드(2301)는 클라이언트들(648A, 648B)로부터의 이들 2개의 요청들(675A1, 675B)이 스케쥴링된 요청들(675)일 것이며, 제1 클라이언트(648A)로부터의 제1 요청(675A1)이 제2 클라이언트(648B)로부터의 제2 요청(675B)에 관해 시간상 더 일찍 완료될 것임을 스케쥴러(2101)에 표시한다.
사용자 스레드(2301)는 이후 블록들(675A1, 675B)에 의해 표현된 바와 같이 요청들(675A1, 675B)을 발행한다. 제1 클라이언트(648A)로부터의 제1 요청(675A1)이 제2 클라이언트(648B)로부터의 제2 요청(675B) 이전에 발생할 것인 반면, 사용자 스레드(2301)는 임의의 순서로 요청들(675)을 발행할 수 있다. 따라서, 도 25에 예시된 바와 같이, 제2 클라이언트로부터의 제2 요청(675B)은 스테이지(2502)에서 제1 클라이언트로부터의 제1 요청(675A1) 이전에 스테이지(2501)에서 발행된다.
스케쥴러(2101)는 이 스테이지에서 데이터베이스(2103)에 발행된 요청들(675 157B1, 157B2)로부터의 데이터를 레코딩하고, 요청(675)이 타이머(2105)와 함께 작용함으로써 프로세싱될 시간을 설정한다. 구체적으로, 스케쥴러(2101)는, 도 15-16에 관련하여 전술된 바와 같이, 특정 트리거들(314)를 타이머(2105)에 통지한다. 트리거들(314)은 각각의 요청(675 A1, 675B)이 언제 시작되어야 하는지를 나타낸다.
타이머가 위에서 주지된 스케쥴러(2101)에 의해 타이머(314)에 통신된 트리거들에 부합할 수 있는 스테이지(2505A)에서 만료할 때, 블록(2101A)에서의 스케쥴러(2101)는 블록(2510A1)에서 제1 요청(675A1)을 프로세싱할 수 있다. 이후, 블록(2515A)에서, 스케쥴러(2101)는 제1 요청(675A1)이 스케쥴러(2101)에 의해 완료되었다는 통지를 클라이언트에게 발행할 수 있다.
블록(2510B)에서, 스케쥴러(2101)는 이후 제2 요청(675B)을 프로세싱할 수 있다. 이후, 블록(2515B)에서, 스케쥴러(2101)는 제2 요청(675B)이 스케쥴러(2101)에 의해 완료되었다는 통지를 클라이언트에게 발행할 수 있다. 이전에 주지된 바와 같이, 제1 요청(675A1)은 제1 요청(675A1)이 제2 요청(675B)에 대한 종료(finish 또는 end) 시간보다 더 이른 종료 시간을 가지기 때문에 제2 요청(675B) 이전에 프로세싱되었다.
일 예시적인 실시예에 따르면, 스케쥴러는 우선-도착 우선-서빙 기반으로 요청들(675)을 관리한다. 이것은, 둘 이상의 요청들(675)이 동일한 원하는 종료 시간 또는 완료 시간을 가지는 경우, 스케쥴러(2101)가 스케쥴링을 위해 스케쥴러(2101)에 먼저 도달한 요청(675)을 프로세싱하고 완료할 수 있음을 의미한다. 추후-도착-예정 요청(675)은 스케쥴러(2101)에서, 두 요청들 모두(675)가 동일한 완료 데드라인을 가질 수 있음에도, 시간상 스케쥴러(2101)에 먼저 도달하는 요청(675) 다음에 완료될 것이다.
따라서, 도 25에 예시된 예시적인 실시예에 대해, 제1 및 제2 요청들(675A1, 675B) 모두가 동일한 원하는 완료 시간을 가진 경우, 제2 요청(675B)은 제2 요청(675B)이 제1 요청(675A1)이 도착하기 이전에 먼저 스케쥴러(2101)에 도착하기 때문에 제1 요청(675A1) 이전에 완료되었을 것이다. 이후, 블록들(2510A1 및 2515A)과 블록들(2510B 및 2515B)이 제1 요청(675A1)의 완료 이전에 제2 요청(675B)의 완료를 반영하기 위해 역전되는 것이 후속한다.
그러나, 스케쥴러(2101)는 우선-도착 우선-서빙 프로토콜의 이러한 예시적인 실시예에 제한되지 않는다. 다른 예시적인 실시예들에서, 스케쥴러(2101)는 요청들(675)이 얼마나 빨리 완료될 수 있는지 그리고/또는 그 완료가 휴대용 컴퓨팅 디바이스(100)에 대한 전력 절감들에 대해 얼마나 영향을 미칠 수 있는지에 따라 스케쥴러(2101)가 요청들(675)을 스케쥴링하게 하는 기능성을 제공받을 수 있다.
일부 예시적인 실시예들에서, 요청들(675) 사이의 타이밍에서 오버랩이 존재하지 않을 수 있다. 예를 들어, 제1 요청(675A1)이 10 ms의 백오프를 가지고 100의 가설적 시간 데드라인에서 완료되도록 요구된 경우, 그리고 제2 요청(675B)이 10ms의 백오프를 가지고 시간 150에서 완료되도록 요구되는 경우, 이들 타이밍들을 가지는 이들 2개의 요청들(675A1, 675B)의 스케쥴링에서 오버랩이 존재하지 않는다. 이러한 예시적인 시나리오에서 각각의 요청(675)에는, 2개의 타이머 이벤트들이 이들 2개의 오버랩하지 않은 요청들(675A1, 675B)을 프로세싱하기 위해 설정되도록, 자신의 고유한 타이머 이벤트가 제공된다.
일반적으로, 다수의 요청들(675)은 다수의 요청들(675) 사이의 시간상 일부 오버랩이 존재할 때, 스케쥴러(2101)에 의해 접히고(collapsed) 프로세싱될 수 있다. 요청들(675) 간의 오버랩은 타이밍 뿐만 아니라 요청들(675)을 프로세싱하기 위해 요구되는 시스템 오버헤드의 견지에서 정의될 수 있다.
예를 들어, 스케쥴러(2101)는 2개의 요청들(675)에 대한 요청된 데드라인들이 서로 상당히 떨어져 있는 경우 2개의 별도의 타이머 이벤트들을 생성하기 보다는, 동시에 또는 순차적으로 2개의 요청들(675)을 프로세싱하는 것이 더 효율적인지를 결정할 수 있다. 다시 말해, 스케쥴러(2101)가 2개의 요청들(675)을 동시에 또는 순차적으로 스케쥴링하는 것이 타이머(2105)를 이용하여 2개의 별도의 타이머 이벤트들을 생성하는 것보다 더 효율적일 것이라고 결정하는 경우 스케쥴러(2101)는 요청된 완료 데드라인들을 무효화시킬 수 있다.
요청된 데드라인 이전에 요청들(675)이 언제 프로세싱되어야 하는지에 대한 스케쥴러(2101)에 의한 이러한 효율성 결정은 PCD(100)의 전력 소모를 고려할 수 있다. 스케쥴러(2101)가, PCD(100)가 하나 이상의 요청들(675)을 프로세싱하기에 더 낮은 전력을 가질 수 있는 요청된 데드라인에 비해 동시에 요청들(675)을 프로세싱하기에 충분한 전력을 가진다고 결정하는 경우, 스케쥴러(2101)는 이들의 요청된 데드라인들보다 더 이르게 요청들(675)을 스케쥴링할 수 있다. 스케쥴러(2101)는 특정 요청(675)이 "온(ON)" 상태와 관련되는지 또는 특정 요청(675)이 "오프(OFF)" 상태와 관련되는지를 결정함으로써 요청들(675)의 전력 소모를 트래킹할 수 있다.
도 26은 클라이언트(648A)를 통한 사용자 스레드(2301)가 특정 요청(675)이 프로세싱되게 하기를 더 이상 원하지 않는다고 결정할 수 있을 때, 예시적인 타이밍도(2600)를 예시한다. 이러한 요구되지 않는 또는 원치 않는 요청들(675)은 스케쥴링되지 않은 요청들(675)로서 특성화된다.
스케쥴링되지 않은 요청들(675), 즉, (a) 스케쥴러(2101)에 의해 프로세싱되지 않은 요청들(675), 및 (b) 스케쥴러(2101)에 의해 동시에 프로세싱된 요청들에 대한 2개의 상황들이 존재한다. 도 26-27은 스케쥴러(2102)에 의해 생성되었지만 프로세싱되지는 않은 요청들(675)을 예시한다. 한편, 도 28은 생성되어 스케쥴러(2101)에 의해 프로세싱되는 요청들(675)을 예시하고, 이후 클라이언트(648)가 요청(675)이 프로세싱되는 동안 스케쥴링되지 않은 요청 커맨드를 발행한다.
도 26을 다시 참조하면, 클라이언트(648A)는 블록(648A)에 의해 표현된 바와 같은 스테이지(1205A)에서 생성된다. 요청(675)이 클라이언트(648A)에 의해 발행되기 이전에, 스케쥴링되지 않은 요청 커맨드가 스테이지(2610)에서 발행된다. 이 시나리오에서, 스케쥴러(2101)는 일반적으로 데이터베이스(2103)에 저장된 스케쥴링된 요청들(675)의 리스트로부터 요구되지 않는 요청들(675)을 단순히 제거할 수 있다. 스테이지(2615)에서, 새로운 즉시 요청이 (예시된 바와 같이) 스케쥴링되지 않고 발행될 수 있거나 또는 또다른 스케쥴링된 요청이 시작될 수 있다(클라이언트에 대해 1205A 및 648A를 반복함).
도 27은 요청(675)이 스케쥴링되고 사용자 스레드(2301)가 스테이지(2705)에서 요청(675)을 발행하지만, 스케쥴링되지 않은 요청 커맨드(2605)가 발행될 때 스케쥴러(2101)가 요청(675)의 프로세싱을 시작하지 않은 타이밍도(2700)를 예시한다. 구체적으로, 전술된 바와 같이, 스케쥴링된 클라이언트(648A)는 도 12와 부합하는 블록(1205A)에서 생성된다.
이후, 스테이지(2705)에서, 클라이언트(648A)는 요청(675)을 발행한다. 스테이지(2305A)에서, 하나 이상의 요청들(675)에 대한 시작 시간들을 가지는 데이터베이스(2103)는 이후 업데이트될 것이다. 이후, 스테이지(2305B)에서, 스케쥴링되지 않은 요청 커맨드(2605)는 클라이언트(648A)에 의해 발행된다. 이 점에서, 데이터베이스(2103)는 요청(675)이 데이터베이스(2103)로부터 제거될 수 있는 스케쥴러(2102)에 의해 업데이트될 수 있다. 요청(675)은 요청(675)이 스케쥴러(2101)에 의해 프로세싱되지 않기 때문에 데이터베이스(2103)로부터 제거될 수 있다(즉, 요청(675)은 요청된 리소스(105)에 송신되지 않음). 이 스테이지에서, 또다른 즉시 또는 스케쥴링된 요청이 시작될 수 있다.
도 28은 요청(675)이 스케쥴링되고 사용자 스레드(2301)가 요청(675)을 발행하고, 스케쥴러가 요청(675)을 프로세싱하기 시작하는 예시적인 타이밍도(2800)를 예시한다. 다시 말해, 스케쥴러(2101)는 이제 클라이언트(648) 또는 사용자 스레드(2301)에 의해 요구되지 않는 요청(675)을 이미 프로세싱하기 시작한다.
이 예시적인 실시예에 따르면, 사용자 스레드(2301) 또는 클라이언트(648)가 스테이지(2805)에서 스케쥴링되지 않은 요청 커맨드(2605)를 발행할 때, 스케쥴러(2101)는 블록(2810)에 의해 표시된 바와 같이 스케쥴링되지 않은 요청 커맨드를 차단하는 블록(2815)에 의해 예시된 바와 같이 리소스(105)에 대한 잠금을 발행한다. 이러한 방식으로, 스케쥴러(2101)는 스테이지(2805)에서 발행된 스케쥴링되지 않은 요청 커맨드(2605)와는 무관하게 블록(2505)에서 스케쥴링된 요청(675)을 완료한다.
따라서, 도 28의 이러한 예시적인 실시예에서, 스테이지(2805)에서 스케쥴링되지 않은 요청 커맨드(2605)에 응답하여, 사용자 스레드(2301) 또는 클라이언트(648)는 클라이언트 통지(2510) 뿐만 아니라 요청(675)이 프로세싱/완료된다는 스케쥴링되지 않은 요청 커맨드(2605)에 대한 리턴 값을 수신할 수 있다.
요청(675)이 슬립 LPR(2107)에 의해 완료될 리소스 세트(304)의 다음-어웨이크 세트에 배치되고 사용자 스레드(2301)가 스케쥴링되지 않은 요청 커맨드(2605)를 발행하고, 시스템이 깨어날 때까지 클라이언트 통지(2510)가 발행되지 않은 시나리오에서, 스케쥴러(2101)는 스케쥴러(2101)가 요청(675)에 대해 즉시 작용하게 하는 요청(675)의 우선순위를 내포할 수 있다.
이것은 사용자 스레드(2301)와 스케쥴러(2101)가 요청된 데드라인을 대기하기보다는 요청(675)을 즉시 종료하게 하는 동기화 포인트가 된다. 스케쥴러(2101)는 요청(675)이 완료되었고 따라서 스케쥴링되지 않은 요청 커맨드(2605)가 또한 완료되었음을 표시하는 사용자 스레드(2301)에 통지를 다시 발행할 것이다.
도 29는 단일의 응용 프로그램이 실행 중이고, 활성 상태 동안 하나 이상의 요청들(675)을 프로세싱한 이후, CPU(110)가 슬립 상태(2902)로 진입할 수 있는 단순한 시나리오를 예시한다. Y-축은 전압 또는 전류를 나타낼 수 있는 반면 X-축이 예컨대 밀리초 단위로 시간을 표현할 수 있다.
스테이지들 1 및 2 사이에서, 단일 애플리케이션이 실행중이고, CPU(110)는 활성이고, 5 밀리볼트와 같은 전압을 가진다. 이후, CPU(110)는 영전압이 존재하는 X-축 시간선 상의 스테이지들(2 및 3) 사이에서 슬립 상태(2902)로 진입한다. 유사하게, X-축 상의 단계들(3 및 4) 사이에, CPU(110)는 활성이며, 다시 5 밀리볼트와 같은 전압을 가진다.
도 21에서 전술된 바와 같이, 스테이지 1.1에서, 사용자 스레드(2301)(예시되지 않음)는 CBM("CPU busy monitor") 리소스(2109)에 대한 요청을 발행할 수 있다. CBM 리소스(2109)는 스케쥴러(2101)의 일부분이거나 그리고/또는 스케쥴러(2101)에 의해 설정된다. CBM 리소스(2109)에 대한 임의의 넌제로 요청들(675)은 요청(675)을 발행하는 클라이언트(648) 또는 사용자 스레드(2301)는 CPU(110)가 요청(675)의 실행 동안 비지 상태를 유지하는 것을 예상한다. CBM 리소스(2109)는 CPU(110)가 임의의 클라이언트(648)가 비지상태인 한 CBM 리소스(2109)에 의해 비지상태인 것으로 고려되고 마지막 클라이언트(675)가 넌제로 또는 비지 요청을 완료할 때까지 CPU(110)가 자유롭거나 비지상태가 아닌 것으로서 특성화되지는 않음을 의미하는 바이너리 리소스이다.
스테이지 1.2에서, 억제가능한 리소스 요청(675)은 리소스(105)에 스케쥴러(2101)에 의해 발행될 수 있다. 억제가능한 요청(675)은 억제가능한 클라이언트(648)로부터 발행된 리소스 요청(675)이고, 이들 요청들(675)은 CPU(110)가 유휴상태가 되거나 슬립 상태(2902)에 진입할 때 이들 요청들(675)이 받아들여질 필요가 없다는 특징을 가진다. 다시 말해, 억제가능한 요청들(675)은 CPU(110)가 슬립 상태(2902)로 진입할 때 "셧 오프"될 수 있다.
억제가능한 요청들(675)은 CPU(110)에 의해 항상 받아들여지도록 요구되는, 요구되는 요청들(675)에 직접 대비된다. 스테이지 2에서 억제가능한 요청(675)을 발행함으로써, 슬립 상태(2902)에 진입하기 이전에 요청(675)을 명시적으로 취소하기 위한 요건이 존재하지 않는다.
RPM(157)에 의해 서비스되는 리소스들(105)의 특정 경우에서, 억제가능한 요청(675)은 리소스 세트(304)의 슬립 세트에 추가되지 않고, 리소스 세트(304)의 활성 세트에만 추가된다. 반면, 요구되는 요청(675)은 당업자에 의해 이해되는 바와 같이, 슬립 세트(304)(도 15 참조)의 활성 및 슬립 세트들 모두에 추가된다.
스테이지 2.1에서, 일단 요청(675)이 리소스(105)에 의해 완료되면, 리소스(105)는 스케쥴러(2101)의 CBM 리소스(2109)에, 리소스(105)가 "곧" 유휴상태가 될 것으로 예상됨을 나타내는 통지를 발행한다. 스테이지 2.1에서의 리소스는 요청(675)의 완료에 따라 클린-업(clean-up) 작업을 수행하기 시작한다.
슬립 상태(2902)의 바로 앞의 스테이지 2.2에서, 클라이언트(648) 또는 사용자 스레드(2301)는 임의적(discretionary) 기능/특징을 사용하여 새로운 요청(211)을 스케쥴링하고, X-축 상의 스테이지 3에서 새로운 요청(2111)이 프로세싱될 필요가 있음을 스케쥴러(2101)에 표시할 수 있다. 임의적 기능 또는 특징은 새로운 요청(2111)의 일부분인 데이터를 포함할 수 있다.
임의적 기능은 클라이언트(648)가 완료된 이전 요청(675) 또는 현재 요청(675)이 작용할 때까지 지속될 것이라는 기대를 가지지 않음을 스케쥴러(2101)에 통지한다. 다시 말해, 새로운 요청(2111)의 일부분인 이러한 추가적인 임의적 기능 또는 특징을 통해, 스케쥴러(2101)는 새로운 스케쥴링된 요청(2111)이 실행될 때 프로세싱되는 현재 클라이언트 요청(675)이 이 프로세싱을 완료하거나 계속할 필요가 없음을 인식할 것이다. 이러한 임의적 기능을 통해, 스케쥴러(2101)는 스케쥴러(2101)의 임의로 현재 요청(675)을 완료하기 위한 요청이 아닌 자유를 가진다.
스테이지 2에서, 스케쥴러(2101)는 CBM 리소스(2109)에 의해 트래킹되는 CPU(110)의 현재 상태를 리뷰할 수 있다. 스케쥴러(2101)가 CPU(110)가 CBM 리소스(2109)에 의해 트래킹되는 것으로서 비지 상태에 있지 않음을 통지하는 경우, 스케쥴러(2101)는 (도 15의 제어기(101)와 리소스 세트들을 통해) 슬립 상태가 임의적 기능을 통해 발행된 새로운 요청(2111)을 취소할 필요 없이 스테이지들 2와 3 사이에서 유휴 또는 슬립 상태 동안 CPU(110)를 턴 오프하게 할 수 있다. 이러한 방식으로, 리소스 세트들(304)의 슬립 세트를 통해 RPM(157)(도 15 참조)은 실제 슬립 상태(2902)에 진입하기 이전에 어떠한 취소 요청들도 발행할 필요가 없다.
요약하면, 스케쥴러(2101)는 슬립 상태가 CPU(110)에 대해 곧 예상되는지를 결정하기 위해 CBM 리소스(2109)에 의해 트래킹된 비지 상태를 조사할 수 있다. 새로운 요청(2111)의 임의적 기능을 통해, 스케쥴러(2101)는 현재 요청(675)을 종료/취소할지를 결정하고, 슬립이 곧 발생할 것임을 예상하는 경우 새로운 요청(2111)을 스케쥴링할 수 있다.
대안적으로, 스케쥴러(2101)는 현재 요청(675)과 새로운 요청(2111)이 유사하거나 동일하다고 인지하는 경우 현재 요청(675)을 취소/종료하지 않고, 새로운 요청(2111)을 받아들이지 않기로 결정할 수 있다. 이는 RPM(157)이 제어기(100)의 슬립 세트를 통해 CPU(110)를 턴오프하고 이후 현재 요청(675)이 CPU(110)가 턴온되었을 때 프로세싱되도록 CPU(110)를 턴온하게 할 것이다.
새로운 요청(2111)의 이러한 임의적 기능/특징은 스케쥴러(2101)가 현재 요청(675)을 취소할지 또는 새로운 요청(2111)을 발행할지를 결정하게 한다. 이러한 임의적 기능 및 CBM 리소스(2109)에 의해 트래킹되는 비지 상태를 리뷰함으로써 슬립 상태들을 예상하기 위한 스케쥴러(2101)의 능력은 시스템(2100)의 효율성을 증가시키고 전력을 보존한다. 전력은 스케쥴러(2101)가 클라이언트들(648)로부터 수신하는 요청들(675)에 대해 스케쥴러(2101)가 재량(discretion)을 가지게 하지 않는 시스템에 비해 그만큼 많은 작업을 수행할 필요가 없기 때문에 전력이 절감될 수 있다.
스케쥴러(2101)가 RPM(157)과 제어기(101)(도 15 참조)에 의해 관리되는 리소스 세트들의 활성 세트와 슬립 세트들로 임의의 파라미터들을 조정할 필요가 없기 때문에, 작업은 CBM 리소스(2109) 및 새로운 요청들(2111)에서의 임의적 기능들을 사용하여 스케쥴러(2101)에 의해 감소한다. 스케쥴러(2101)가 CPU(110)의 연속적인 활성 상태들이 서로 유사하고 활성 또는 슬립 세트들에 대한 어떠한 변경들도 요구하지 않음을 결정할 수 있기 때문에, 슬립 세트들 및 활성 세트들의 어떠한 파라미터들에 대한 조정들도 요구되지 않는다.
RPM(157)과 제어기(101)에 의해 관리되는 리소스 세트들의 활성 또는 슬립 세트들을 조정하지 않고, 15% 정도에 대한 효율성들은 발명의 시스템(2100)을 이용하여 구현되었다(즉, 스케쥴러(2101)가 현재 및 새로운 요청들(675)을 받아들이고/취소하는 것에 대한 재량을 가지게 하지 않는 시스템들에 비해, 45ms 중 7 ms 정도 또는 그 이상에 대한 시간 절감들이 달성된다).
이전에 주지된 바와 같이, 스케쥴러(2101)는 CBM 리소스(2109)를 가지는 시스템(2100)의 효율성을 증가시킬 수 있다. CBM 리소스(2109)는 스케쥴러(2101)가 슬립 상태가 비교적 곧 발생하지 않을 것임을 추론하게 하는 시스템(2100)에서 무언가가 발생하는지의 여부에 대한 바이너리 표시자이다.
CBM 리소스(2109)가, 일반적으로 대부분의 또는 모든 시스템 엘리먼트들이 확장적인 작업량이 리소스들(105)에 대해 스케쥴링되지 않았으며, 그 리소스들(105)이 요청들(675)에 대해 완전히 자유로워질 것임을 의미하는 "비지"가 아님을 표시할 때, 이후 스케쥴러(2101)는 슬립 상태(2902)가 상대적으로 곧 발생할 것임을 예상할 수 있다. CBM 리소스(2109)에 의해 트래킹된 상태들을 봄으로써, 스케쥴러(2101)는, 슬립 상태(2902)가 발행할 것인지를 스케쥴러(2101)가 예상하는지의 여부에 따라 리소스들이 파워오프되어야 하는지에 대한 결정을 수행할 수 있다.
예를 들어, 스케쥴러(2101)가 모든 리소스들(105)이 넌-비지 상태를 현재 등록함을 통지하는 경우, 스케쥴러(2101)는 슬립 상태(2902)가 발생할 것을 예상할 수 있고, 스케쥴러(2101)는 슬립 상태(2902)가 (자신의 리소스 세트들을 가지는 RPM(157)과 제어기(101)를 통해) 하나 이상의 리소스들(101)을 파워오프하게 하여 스케쥴러(2101)가 이들 작업들을 수행할 필요가 없고 따라서 작업을 절감한다.
또다른 예에서, 스케쥴러(2101)가 제1 리소스(105A)가 넌-비지 상태에 등록되는(즉, 제1 리소스(105A)가 비활성) 반면, 제2 리소스(105B)가 비지 상태에 등록함을 표시하는 경우, 그리고 스케쥴러(2101)가 제1 리소스(105A)가 어떠한 차후 요청들(675)에 대해서도 스케쥴링되지 않는다고 결정하는 경우, 스케쥴러(2101)는 전력을 절감하기 위해 넌-비지상태의 제1 리소스(105A)를 파워다운시킬 수 있다. 넌-비지상태의 제1 리소스(105A)를 파워 다운시키는 이러한 동작은, 제2 리소스(105B)가 비지 상태에 등록되기 때문에 슬립 상태(2902)가 예상되지 않으므로 전체 전력을 보조할 수 있다. 넌-비지상태의 제1 리소스(105A)가 "온"이지만 비활성 상태에서 유지하도록 허용되는 경우 전력이 낭비될 수 있다.
도 30은 스테이지들(3015와 3030) 사이에 발행할 스케쥴링된 슬립 상태 동안 스케쥴러(2101)가 예상되지 않은 웨이크-업들 또는 인터럽션들(3002B)을 관리하는 방법에 관한 예시적인 시나리오를 예시한다. X-축은 밀리초 단위인 시간을 나타낼 수 있는 반면, Y-축은 전류 또는 전압을 나타낼 수 있다.
스케쥴러(2101)는 CPU(110)의 비지 또는 활성 상태(3002A)의 스테이지(3005)의 시작에서 하나 이상의 리소스들에 대한 하나 이상의 요청들(675)을 관리한다. 스테이지(3015)에서 슬립 상태에 진입하기 이전에, 데이터베이스(2103)를 리뷰한 이후 스케쥴러(2101)는 스테이지(3030)에 대해 스케쥴링된 다음으로 스케쥴링된 비지 또는 활성 상태(3002C)에서 현재 활성인 리소스의 현재 상태가 변경되지 않을 것임을 인식한다.
따라서, 스테이지(3015) 이전에, 스케쥴러(2101)는 추가적인 작업을 회피하고, 리소스들을 셧 다운하거나 셧 오프하는 프로세스를 겪지 않음으로써 에너지를 보존한다. 따라서, 스테이지(3015)에서, 스케쥴러(2101)는 모든 리소스들(105)이 슬립 상태로 진입하게 하고 각각의 리소스(105)의 슬립 세트가 각자의 리소스(105)를 파워다운시키게 한다. 스테이지(3015)에 진입할 때, 스케쥴러(2101)는 스테이지(3030)에서 시스템이 깨어나는 것을 예상한다.
다시 말해, 스케쥴러(2101)는 스테이지(3020)에서, 웨이크-업(3002B)을 예상하지 않는다. 그러나, 스테이지(3020)에서, 스케쥴러(2101)는 스테이지(3020)에서 웨이크-업 및 예상되지 않은 활성 상태(3002B)를 야기하는 예상되지 않은 인터럽트를 수신한다. 스케쥴러(2101)는 활성 상태(3002B)가 데이터베이스(2103)에 존재하는 타이밍 데이터를 비교함으로써 예상되지 않는다고 결정할 수 있다. 구체적으로, 스케쥴러(2101)가, 현재 디바이스 상태(3002B)가 스테이지(3030)에서 스케쥴링된 웨이크-업 시간보다 시간상 훨씬 더 일찍 발생했음을 통지하는 경우, 스케쥴러(2101)는 이러한 제2 활성 상태(3002B)가 시스템에 의해 예상되지 않거나 예견되지 않음을 인지할 것이다.
이 스테이지(3020)에서, 스케쥴러(2101)는 시스템이 스테이지(3015)에서 시작한 이전에 스케쥴링된 슬립 상태를 이탈할 때 활성이도록 스케쥴링된 리소스(105)가 현재 인터럽트 또는 웨이크업 이벤트(3002B)에 대해 요구되지 않는다고 결정한다. 따라서, 스케쥴러(2101)는 리소스(105)가 사용되지 않는 이러한 예견되지 않은 제2의 활성 상태(3002B) 동안 리소스(105)가 턴오프되도록 리소스(105)에 취소 요청(3007)을 발행할 수 있다.
다음으로, 스테이지(3025)에서 제2의 예상되지 않은 활성 상태(3002B)의 종료에서, 스케쥴러(2101)는 요청(2111)이 (스케쥴러(2101)에 의해 이전에 예견/스케쥴링된) 제3 활성 상태(3002C)에서 다음 활성 어웨이크 세트(304)의 일부분이 되도록 새로운 요청(2111)이 리소스(105)를 턴온시키도록 스케쥴링하기 위해 슬립 LPR(2107)과 통신할 수 있다. 이러한 방식으로, 스케쥴러(2101)는 도 30의 예상되지 않은, 제2의 활성 상태(3002B)와 같은 인터럽트 상태들에 대해 요구되지 않을 수 있는 요청들(675)을 따르거나 재스케쥴링하기 위한 지능(intelligence)을 가진다.
예를 들어, 도 30의 리소스(105)가 RF 모뎀이라고 가정한다. 스케쥴러(2101)는, 임의로, 리소스(105)의 슬립 세트가 RF 모뎀을 턴오프시켜, RF 모뎀이 스테이지(3030)에서 스케쥴링된 다음 예견되는 활성 상태(3002C)에 대해 즉시 활성이 될 것이라고 결정한다.
그러나, 스케쥴러(2101)는 이 스테이지(3020)에서 예상되지 않은 웨이크-업을 야기시키는 인터럽트가 RF 모뎀을 요구하지 않는 응용 프로그램과 연관됨을 습득한다. 스케쥴러(2101)는 이후 RF 모뎀에 대해 취소 요청(2111)을 발행할 수 있고, 따라서, 스케쥴러(2101)는 스테이지(3020)에서의 이러한 예견되지 않은 활성 상태(3002B) 동안 이전 요청(675)에 대응하는 스케쥴러(2101)의 스케쥴링된 작업을 수행하지 않는다. 스케쥴러(2101)는, 슬립 LPR(2107)을 사용하여, 이후, 스테이지(3030)에서 예상된 그리고 이전에 스케쥴링된 활성 상태(3002C)에서 NAS(next awake set)(304)에 대해 RF 모뎀과 연관된 새로운 요청(2111)을 스케쥴링할 것이다.
위의 개시내용의 견지에서, 당업자는 이 명세서에서의 흐름도들 및 연관된 설명에 기초하여 어려움 없이 분배된 리소스 관리 시스템 및 방법을 구현하기 위해 컴퓨터 코드를 기록하고 적절한 하드웨어 및/또는 다른 로직 또는 회로를 식별할 수 있다. 따라서, 프로그램 코드 명령들의 특정 세트 또는 상세화된 하드웨어 디바이스들의 개시내용은 분배된 리소스 관리 시스템 및 방법을 제작하고 사용하는 방법에 대한 적절한 이해를 위해 필요한 것으로 간주되지는 않는다. 청구된 컴퓨터 구현 프로세스들의 발명의 기능성은 다양한 프로세스 흐름들을 예시할 수 있는 도면 도식들과 함께 그리고 위의 기재에서 더 상세하게 설명되어 있다. 또한, 프로세서들(110, 126, 202, 206 등)은, 메모리(112) 및 메모리(112)에 저장된 명령들과 함께, 본원에 설명된 방법 단계들 중 하나 이상을 수행하기 위한 수단으로서 역할을 할 수 있다.
하나 이상의 예시적인 양상들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 결합에서 구현될 수 있다. 소프트웨어에서 구현되는 경우, 기능들은 컴퓨터-판독가능한 매체 상에 하나 이상의 명령들 또는 코드로서 저장되거나 전송될 수 있다. 컴퓨터-판독가능한 매체는 한 장소에서 또다른 장소로의 컴퓨터 프로그램의 이전을 용이하게 하는 임의의 매체를 포함하는 통신 매체와 컴퓨터 저장 매체 모두를 포함한다. 저장 매체는 컴퓨터에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있다. 제한이 아닌 예시에 의해, 이러한 컴퓨터-판독가능한 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광 디스크 저장, 자기 디스크 저장 또는 다른 광 또는 자기 저장 디바이스들, 또는 명령들 또는 데이터 구조들의 형태로 원하는 프로그램 코드를 반송하거나 저장하기 위해 사용될 수 있으며 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 용어 "디스크" 또는 "disc"는, 본원에서 사용된 바와 같이, 컴팩트 disc("CD"), 레이저 disc, 광 disc, 디지털 다목적 disc("DVD"), 플로피 disk 및 블루-레이 disc를 포함하지만 이에 제한되지 않는다. 위 항목들의 결합들이 또한 컴퓨터-판독가능한 매체의 범위 내에 포함되어야 한다.
선택된 양상들이 예시되고 상세히 설명되었지만, 다양한 치환들 및 대안들이이 후속하는 청구항들에서 정의된 바와 같은 본 개시내용의 사상과 범위로부터 이탈하지 않고 본원에서 이루어질 수 있다는 점이 이해될 것이다.

Claims (40)

  1. 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법으로서,
    각각의 요청이 적어도 하나의 리소스 및 요청된 데드라인을 식별하는, 복수의 요청들을 스케쥴링하기 위한 클라이언트로부터의 데이터를 수신하는 단계;
    데이터베이스에 상기 클라이언트로부터의 데이터를 저장하는 단계;
    상기 요청들 내의 요청된 데드라인들에 기초하여 그리고 휴대용 컴퓨팅 디바이스 내의 리소스들의 현재 상태들에 기초하여 상기 요청들을 프로세싱하기 위한 시간들 및 시퀀스(sequence)를 결정하는 단계; 및
    상기 결정된 시간들에서 그리고 상기 결정된 시퀀스에 따라 상기 리소스들에 대한 요청들을 통신하는 단계를 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법.
  2. 제1항에 있어서,
    새로운 요청 커맨드(command)를 수신하는 것에 응답하여 요청된 데드라인 이후에 요청을 스케쥴링하는 단계를 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법.
  3. 제1항에 있어서,
    프로세서가 슬립 프로세서 상태를 이탈했을 때 하나 이상의 요청들에 대한 작용을 계속할 수 있도록 상기 슬립 프로세서 상태에 대응하는 슬립 세트가 상기 프로세서를 파워 오프(power off)하게 하는 단계를 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법.
  4. 제1항에 있어서,
    스케쥴링된 슬립 상태 동안 예상되지 않은 요청을 수신하는 단계;
    상기 예상되지 않은 요청을 수신하는 것에 응답하여, 하나 이상의 스케쥴링된 요청들이 상기 예상되지 않은 요청에 응답하도록 요구되는지를 결정하는 단계를 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법.
  5. 제4항에 있어서,
    하나 이상의 스케쥴링된 요청들이 상기 스케쥴링된 슬립 상태 동안 상기 예상되지 않은 요청에 응답할 필요가 없는 경우, 하나 이상의 스케쥴링된 요청들을 취소하는 단계를 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법.
  6. 제5항에 있어서,
    상기 취소된 스케쥴링된 요청들 중 하나 이상을 다음 스케쥴링된 활성 상태에서 발생하도록 재스케쥴링하는 단계를 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법.
  7. 제1항에 있어서,
    이전에 스케쥴링된 요청을 스케쥴링하지 않기 위한 커맨드를 수신하는 단계를 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법.
  8. 제7항에 있어서,
    상기 이전에 스케쥴링된 요청을 스케쥴링하지 않기 위한 커맨드를 수신하는 것에 응답하여 리소스를 잠그는 단계를 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법.
  9. 제8항에 있어서,
    상기 이전에 스케쥴링된 요청을 스케쥴링하지 않기 위한 커맨드를 수신하는 것에 응답하여 리소스를 이용하여 스케쥴링된 요청의 프로세싱을 종료하는 단계를 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법.
  10. 제1항에 있어서,
    상기 휴대용 컴퓨팅 디바이스는 모바일 전화, 개인 디지털 보조 단말, 페이저, 스마트폰, 내비게이션 디바이스, 및 무선 접속 또는 링크를 가지는 핸드헬드 컴퓨터 중 적어도 하나를 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법.
  11. 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템으로서,
    각각의 요청이 적어도 하나의 리소스 및 요청된 데드라인을 식별하는, 복수의 요청들을 스케쥴링하기 위한 클라이언트로부터의 데이터를 수신하고;
    데이터베이스에 상기 클라이언트로부터의 데이터를 저장하고;
    상기 요청들 내의 요청된 데드라인들에 기초하여 그리고 휴대용 컴퓨팅 디바이스 내의 리소스들의 현재 상태들에 기초하여 상기 요청들을 프로세싱하기 위한 시간들 및 시퀀스를 결정하고; 그리고
    상기 결정된 시간들에서 그리고 상기 결정된 시퀀스에 따라 상기 리소스들에 대한 요청들을 통신하도록
    동작가능한 프로세서를 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  12. 제11항에 있어서,
    상기 프로세서는 새로운 요청 커맨드를 수신하는 것에 응답하여 요청된 데드라인 이후에 요청을 스케쥴링하도록 추가로 동작가능한, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  13. 제12항에 있어서,
    상기 프로세서는:
    프로세서가 슬립 프로세서 상태를 이탈했을 때 하나 이상의 요청들에 대한 작용을 계속할 수 있도록 상기 슬립 프로세서 상태에 대응하는 슬립 세트가 상기 프로세서를 파워 오프하게 하도록 추가로 동작가능한, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  14. 제11항에 있어서,
    상기 프로세서는:
    스케쥴링된 슬립 상태 동안 예상되지 않은 요청을 수신하고;
    상기 예상되지 않은 요청을 수신하는 것에 응답하여, 하나 이상의 스케쥴링된 요청들이 상기 예상되지 않은 요청에 응답하도록 요구되는지를 결정하도록 추가로 동작가능한, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  15. 제14항에 있어서,
    상기 프로세서는:
    하나 이상의 스케쥴링된 요청들이 상기 스케쥴링된 슬립 상태 동안 상기 예상되지 않은 요청에 응답할 필요가 없는 경우, 하나 이상의 스케쥴링된 요청들을 취소하도록 추가로 동작가능한, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  16. 제15항에 있어서,
    상기 프로세서는:
    상기 취소된 스케쥴링된 요청들 중 하나 이상을 다음 스케쥴링된 활성 상태에서 발생하도록 재스케쥴링하도록 추가로 동작가능한, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  17. 제11항에 있어서,
    상기 프로세서는:
    이전에 스케쥴링된 요청을 스케쥴링하지 않기 위한 커맨드를 수신하도록 추가로 동작가능한, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  18. 제17항에 있어서,
    상기 프로세서는:
    상기 이전에 스케쥴링된 요청을 스케쥴링하지 않기 위한 커맨드를 수신하는 것에 응답하여 리소스를 잠그도록 추가로 동작가능한, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  19. 제18항에 있어서,
    상기 프로세서는:
    상기 이전에 스케쥴링된 요청을 스케쥴링하지 않기 위한 커맨드를 수신하는 것에 응답하여 리소스를 이용하여 스케쥴링된 요청의 프로세싱을 종료하도록 추가로 동작가능한, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  20. 제11항에 있어서,
    상기 휴대용 컴퓨팅 디바이스는 모바일 전화, 개인 디지털 보조 단말, 페이저, 스마트폰, 내비게이션 디바이스, 및 무선 접속 또는 링크를 가지는 핸드헬드 컴퓨터 중 적어도 하나를 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  21. 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템으로서,
    각각의 요청이 적어도 하나의 리소스 및 요청된 데드라인을 식별하는, 복수의 요청들을 스케쥴링하기 위한 클라이언트로부터의 데이터를 수신하기 위한 수단;
    데이터베이스에 상기 클라이언트로부터의 데이터를 저장하기 위한 수단;
    상기 요청들 내의 요청된 데드라인들에 기초하여 그리고 휴대용 컴퓨팅 디바이스 내의 리소스들의 현재 상태들에 기초하여 상기 요청들을 프로세싱하기 위한 시간들 및 시퀀스를 결정하기 위한 수단; 및
    상기 결정된 시간들에서 그리고 상기 결정된 시퀀스에 따라 상기 리소스들에 대한 요청들을 통신하기 위한 수단을 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  22. 제21항에 있어서,
    새로운 요청 커맨드를 수신하는 것에 응답하여 요청된 데드라인 이후에 요청을 스케쥴링하기 위한 수단을 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  23. 제22항에 있어서,
    프로세서가 슬립 프로세서 상태를 이탈했을 때 하나 이상의 요청들에 대한 작용을 계속할 수 있도록 상기 슬립 프로세서 상태에 대응하는 슬립 세트가 상기 프로세서를 파워 오프하게 하기 위한 수단을 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  24. 제21항에 있어서,
    스케쥴링된 슬립 상태 동안 예상되지 않은 요청을 수신하기 위한 수단;
    상기 예상되지 않은 요청을 수신하는 것에 응답하여, 하나 이상의 스케쥴링된 요청들이 상기 예상되지 않은 요청에 응답하도록 요구되는지를 결정하기 위한 수단을 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  25. 제24항에 있어서,
    하나 이상의 스케쥴링된 요청들이 상기 스케쥴링된 슬립 상태 동안 상기 예상되지 않은 요청에 응답할 필요가 없는 경우, 하나 이상의 스케쥴링된 요청들을 취소하기 위한 수단을 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  26. 제25항에 있어서,
    상기 취소된 스케쥴링된 요청들 중 하나 이상을 다음 스케쥴링된 활성 상태에서 발생하도록 재스케쥴링하기 위한 수단을 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  27. 제21항에 있어서,
    이전에 스케쥴링된 요청을 스케쥴링하지 않기 위한 커맨드를 수신하기 위한 수단을 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  28. 제27항에 있어서,
    상기 이전에 스케쥴링된 요청을 스케쥴링하지 않기 위한 커맨드를 수신하는 것에 응답하여 리소스를 잠그기 위한 수단을 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  29. 제28항에 있어서,
    상기 이전에 스케쥴링된 요청을 스케쥴링하지 않기 위한 커맨드를 수신하는 것에 응답하여 리소스를 이용하여 스케쥴링된 요청의 프로세싱을 종료하기 위한 수단을 더 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  30. 제21항에 있어서,
    상기 휴대용 컴퓨팅 디바이스는 모바일 전화, 개인 디지털 보조 단말, 페이저, 스마트폰, 내비게이션 디바이스, 및 무선 접속 또는 링크를 가지는 핸드헬드 컴퓨터 중 적어도 하나를 포함하는, 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 컴퓨터 시스템.
  31. 내장된 컴퓨터 판독가능한 프로그램 코드를 가지는 컴퓨터 사용가능한 매체를 포함하는 컴퓨터 프로그램 물건으로서, 상기 컴퓨터 판독가능한 프로그램 코드는 휴대용 컴퓨팅 디바이스 내의 리소스들 간의 요청들을 관리하기 위한 방법을 구현하기 위해 실행되도록 적응되고, 상기 방법은:
    각각의 요청이 적어도 하나의 리소스 및 요청된 데드라인을 식별하는, 복수의 요청들을 스케쥴링하기 위한 클라이언트로부터의 데이터를 수신하는 단계;
    데이터베이스에 상기 클라이언트로부터의 데이터를 저장하는 단계;
    상기 요청들 내의 요청된 데드라인들에 기초하여 그리고 휴대용 컴퓨팅 디바이스 내의 리소스들의 현재 상태들에 기초하여 상기 요청들을 프로세싱하기 위한 시간들 및 시퀀스를 결정하는 단계; 및
    상기 결정된 시간들에서 그리고 상기 결정된 시퀀스에 따라 상기 리소스들에 대한 요청들을 통신하는 단계를 포함하는, 컴퓨터 프로그램 물건.
  32. 제31항에 있어서,
    상기 방법을 구현하는 프로그램 코드는:
    새로운 요청 커맨드를 수신하는 것에 응답하여 요청된 데드라인 이후에 요청을 스케쥴링하는 것을 더 포함하는, 컴퓨터 프로그램 물건.
  33. 제31항에 있어서,
    상기 방법을 구현하는 프로그램 코드는:
    프로세서가 슬립 프로세서 상태를 이탈했을 때 하나 이상의 요청들에 대한 작용을 계속할 수 있도록 상기 슬립 프로세서 상태에 대응하는 슬립 세트가 상기 프로세서를 파워 오프하게 하는 것을 더 포함하는, 컴퓨터 프로그램 물건.
  34. 제31항에 있어서,
    상기 방법을 구현하는 프로그램 코드는:
    스케쥴링된 슬립 상태 동안 예상되지 않은 요청을 수신하는 것;
    상기 예상되지 않은 요청을 수신하는 것에 응답하여, 하나 이상의 스케쥴링된 요청들이 상기 예상되지 않은 요청에 응답하도록 요구되는지를 결정하는 것을 더 포함하는, 컴퓨터 프로그램 물건.
  35. 제34항에 있어서,
    상기 방법을 구현하는 프로그램 코드는:
    하나 이상의 스케쥴링된 요청들이 상기 스케쥴링된 슬립 상태 동안 상기 예상되지 않은 요청에 응답할 필요가 없는 경우, 하나 이상의 스케쥴링된 요청들을 취소하는 것을 더 포함하는, 컴퓨터 프로그램 물건.
  36. 제35항에 있어서,
    상기 방법을 구현하는 프로그램 코드는:
    상기 취소된 스케쥴링된 요청들 중 하나 이상을 다음 스케쥴링된 활성 상태에서 발생하도록 재스케쥴링하기 위한 것을 더 포함하는, 컴퓨터 프로그램 물건.
  37. 제31항에 있어서,
    상기 방법을 구현하는 프로그램 코드는:
    이전에 스케쥴링된 요청을 스케쥴링하지 않기 위한 커맨드를 수신하는 것을 더 포함하는, 컴퓨터 프로그램 물건.
  38. 제37항에 있어서,
    상기 방법을 구현하는 프로그램 코드는:
    상기 이전에 스케쥴링된 요청을 스케쥴링하지 않기 위한 커맨드를 수신하는 것에 응답하여 리소스를 잠그는 것을 더 포함하는, 컴퓨터 프로그램 물건.
  39. 제38항에 있어서,
    상기 방법을 구현하는 프로그램 코드는:
    상기 이전에 스케쥴링된 요청을 스케쥴링하지 않기 위한 커맨드를 수신하는 것에 응답하여 리소스를 이용하여 스케쥴링된 요청의 프로세싱을 종료하는 것을 더 포함하는, 컴퓨터 프로그램 물건.
  40. 제31항에 있어서,
    상기 휴대용 컴퓨팅 디바이스는 모바일 전화, 개인 디지털 보조 단말, 페이저, 스마트폰, 내비게이션 디바이스, 및 무선 접속 또는 링크를 가지는 핸드헬드 컴퓨터 중 적어도 하나를 포함하는, 컴퓨터 프로그램 물건.
KR1020147026292A 2012-02-23 2013-02-20 휴대용 컴퓨팅 디바이스에서 요청들을 스케쥴링하기 위한 방법 및 시스템 KR101551321B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261602287P 2012-02-23 2012-02-23
US61/602,287 2012-02-23
US13/418,597 US8793697B2 (en) 2012-02-23 2012-03-13 Method and system for scheduling requests in a portable computing device
US13/418,597 2012-03-13
PCT/US2013/026873 WO2013126415A2 (en) 2012-02-23 2013-02-20 Method and system for scheduling requests in a portable computing device

Publications (2)

Publication Number Publication Date
KR20140127341A true KR20140127341A (ko) 2014-11-03
KR101551321B1 KR101551321B1 (ko) 2015-09-08

Family

ID=49004762

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147026292A KR101551321B1 (ko) 2012-02-23 2013-02-20 휴대용 컴퓨팅 디바이스에서 요청들을 스케쥴링하기 위한 방법 및 시스템

Country Status (6)

Country Link
US (1) US8793697B2 (ko)
EP (1) EP2817717A2 (ko)
JP (1) JP5809366B2 (ko)
KR (1) KR101551321B1 (ko)
CN (1) CN104303149B (ko)
WO (1) WO2013126415A2 (ko)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9179169B2 (en) * 2012-03-14 2015-11-03 Imagine Communications Corp. Adaptive media delivery
US8843936B2 (en) * 2012-05-30 2014-09-23 International Business Machines Corporation Automatically identifying critical resources of an organization
US9619286B1 (en) * 2014-03-20 2017-04-11 EMC IP Holding Company LLC Using request service time as fairness heuristic in locking techniques
US9418348B2 (en) * 2014-05-05 2016-08-16 Oracle International Corporation Automatic task assignment system
US20150339275A1 (en) * 2014-05-20 2015-11-26 Yahoo! Inc. Rendering of on-line content
US10178688B2 (en) 2015-10-06 2019-01-08 Motorola Solutions, Inc. Method of scheduling short uplink transmissions
CN105550032A (zh) * 2015-10-27 2016-05-04 深圳市美贝壳科技有限公司 基于Android系统的CPU优化方法、系统
CN105893120B (zh) * 2016-04-21 2019-07-30 北京京东尚科信息技术有限公司 一种线程同步资源的获取方法和装置
US10542100B2 (en) * 2016-09-16 2020-01-21 Oracle International Corporation Systems and methodologies for defining and scheduling custom actions as cloud operations
JP2019175292A (ja) 2018-03-29 2019-10-10 東芝メモリ株式会社 電子機器、コンピュータシステム、および制御方法
CN109491765B (zh) * 2018-10-09 2021-07-30 创新先进技术有限公司 对跨域业务请求的处理方法及装置
CN113168334A (zh) * 2019-02-22 2021-07-23 深圳市欢太科技有限公司 数据处理方法、装置、电子设备及可读存储介质
CN111861114A (zh) * 2020-06-15 2020-10-30 新智机器人技术服务(江阴)有限公司 一种基于智能制造的产品生产流程调度方法及系统

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6791992B1 (en) * 1999-10-07 2004-09-14 The Regents Of The University Of California Earliest-deadline-first queuing cell switching architecture and method
US6937561B2 (en) * 2000-06-02 2005-08-30 Agere Systems Inc. Method and apparatus for guaranteeing data transfer rates and enforcing conformance with traffic profiles in a packet network
US7137117B2 (en) * 2000-06-02 2006-11-14 Microsoft Corporation Dynamically variable idle time thread scheduling
US6578117B2 (en) 2001-10-12 2003-06-10 Sonics, Inc. Method and apparatus for scheduling requests using ordered stages of scheduling criteria
US7093256B2 (en) * 2002-12-13 2006-08-15 Equator Technologies, Inc. Method and apparatus for scheduling real-time and non-real-time access to a shared resource
JP2005149312A (ja) 2003-11-18 2005-06-09 Toyota Motor Corp タスク管理システム
US8782654B2 (en) * 2004-03-13 2014-07-15 Adaptive Computing Enterprises, Inc. Co-allocating a reservation spanning different compute resources types
US8156500B2 (en) * 2005-07-01 2012-04-10 Microsoft Corporation Real-time self tuning of planned actions in a distributed environment
GB0518516D0 (en) * 2005-09-10 2005-10-19 Ibm Managing a resource lock
JP4377369B2 (ja) 2005-11-09 2009-12-02 株式会社日立製作所 リソース割当調停装置およびリソース割当調停方法
WO2007125942A1 (ja) * 2006-04-26 2007-11-08 Nippon Telegraph And Telephone Corporation 負荷制御装置およびその方法
JP4971676B2 (ja) * 2006-04-28 2012-07-11 ルネサスエレクトロニクス株式会社 割り込み制御回路及び割り込み制御方法
US20080046888A1 (en) 2006-08-15 2008-02-21 Appaji Anuradha K Framework for Rule-Based Execution and Scheduling of Tasks in Mobile Devices
FI122301B (fi) * 2006-08-25 2011-11-30 Atomia Oy Piiri, menetelmä ja järjestely yksinkertaisen ja luotettavan hajautetun väyläarbitroinnin toteuttamiseksi
US7669081B2 (en) 2006-09-27 2010-02-23 Raytheon Company Systems and methods for scheduling, processing, and monitoring tasks
GB2443277B (en) * 2006-10-24 2011-05-18 Advanced Risc Mach Ltd Performing diagnostics operations upon an asymmetric multiprocessor apparatus
US8136113B2 (en) * 2006-12-20 2012-03-13 International Business Machines Corporation Method and apparatus for adjusting sleep time of fixed high-priority threads
US20090182802A1 (en) 2008-01-10 2009-07-16 Microsoft Corporation Mobile device management scheduling
US8077638B2 (en) * 2008-06-26 2011-12-13 Qualcomm Incorporated Methods and apparatus for providing quality of service in a peer to peer network
US8407440B2 (en) * 2008-07-08 2013-03-26 HGST Netherlands B.V. Techniques for scheduling requests for accessing storage devices using sliding windows
GB0816551D0 (en) 2008-09-10 2008-10-15 Omnifone Ltd Mobile helper application & mobile handset applications lifecycles
EP2214100A1 (en) * 2009-01-30 2010-08-04 BRITISH TELECOMMUNICATIONS public limited company Allocation of processing tasks
US20110161963A1 (en) * 2009-12-31 2011-06-30 Nokia Corporation Methods, apparatuses, and computer program products for generating a cyclostationary extension for scheduling of periodic software tasks
US20110252423A1 (en) 2010-04-07 2011-10-13 Apple Inc. Opportunistic Multitasking

Also Published As

Publication number Publication date
WO2013126415A3 (en) 2014-10-16
KR101551321B1 (ko) 2015-09-08
JP2015513735A (ja) 2015-05-14
EP2817717A2 (en) 2014-12-31
CN104303149A (zh) 2015-01-21
US8793697B2 (en) 2014-07-29
US20130227583A1 (en) 2013-08-29
CN104303149B (zh) 2017-11-17
JP5809366B2 (ja) 2015-11-10
WO2013126415A2 (en) 2013-08-29

Similar Documents

Publication Publication Date Title
KR101551321B1 (ko) 휴대용 컴퓨팅 디바이스에서 요청들을 스케쥴링하기 위한 방법 및 시스템
US10949249B2 (en) Task processor
TWI233545B (en) Mechanism for processor power state aware distribution of lowest priority interrupts
US8806502B2 (en) Batching resource requests in a portable computing device
JP5969610B2 (ja) ポータブルコンピューティングデバイスにおける分散リソース管理
US8615755B2 (en) System and method for managing resources of a portable computing device
US10564708B2 (en) Opportunistic waking of an application processor
JP2009187552A (ja) 電力制御システム及び電力制御方法
US20130031560A1 (en) Batching and Forking Resource Requests In A Portable Computing Device
TW201205441A (en) Multi-CPU domain mobile electronic device and operation method thereof
JP2005527906A (ja) 分離式電源管理状態を提供する方法および装置
US9098521B2 (en) System and method for managing resources and threshsold events of a multicore portable computing device
JP2013516711A (ja) 電子デバイスにおける電力を制御するシステムおよび方法
US8943504B2 (en) Tracking and releasing resources placed on a deferred unlock list at the end of a transaction
US20130275791A1 (en) Method and System for Tracking and Selecting Optimal Power Conserving Modes of a PCD
KR101635295B1 (ko) 휴대용 컴퓨팅 디바이스에서의 자원 요청들의 트랜잭션으로의 배칭 및 이러한 트랜잭션의 포킹

Legal Events

Date Code Title Description
A201 Request for examination
A302 Request for accelerated examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20180628

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20190624

Year of fee payment: 5