KR20140057649A - 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리 - Google Patents

휴대용 컴퓨팅 디바이스에서 분산 리소스 관리 Download PDF

Info

Publication number
KR20140057649A
KR20140057649A KR1020147008825A KR20147008825A KR20140057649A KR 20140057649 A KR20140057649 A KR 20140057649A KR 1020147008825 A KR1020147008825 A KR 1020147008825A KR 20147008825 A KR20147008825 A KR 20147008825A KR 20140057649 A KR20140057649 A KR 20140057649A
Authority
KR
South Korea
Prior art keywords
node
processor
client
resource
resources
Prior art date
Application number
KR1020147008825A
Other languages
English (en)
Other versions
KR101618476B1 (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 KR20140057649A publication Critical patent/KR20140057649A/ko
Application granted granted Critical
Publication of KR101618476B1 publication Critical patent/KR101618476B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
    • 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/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G06F9/548—Object oriented; Remote method invocation [RMI]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Stored Programmes (AREA)
  • Multi Processors (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

노드-기반의 리소스 아키텍처를 갖는 휴대용 컴퓨팅 디바이스에서, 제 1 프로세서에 의해 제어되지만 제 2 프로세서에 의해 제어되는 제 2 의 또는 네이티브 노드에 대응하는 제 1 의 또는 분산 노드는 제 2 노드의 리소스에 간접적으로 액세스하는데 사용된다. 아키텍처를 정의하는 리소스 그래프에서, 각각의 노드는 하나 이상의 리소스들의 기능성의 캡슐화를 나타내고, 각각의 에지는 클라이언트 요청을 나타내며, 인접 노드는 리소스 의존성들을 나타낸다. 제 1 그래프에 의해 정의되는 리소스들은 제 2 프로세서가 아닌 제 1 프로세서에 의해 제어되며, 제 2 그래프에 의해 정의되는 리소스들은 제 1 프로세서가 아닌 제 2 프로세서에 의해 제어된다. 제 1 노드에서의 클라이언트 요청은 제 1 프로세서의 제어하에 클라이언트로부터 수신될 수도 있다. 그 후에, 클라이언트 요청은 제 1 노드에서의 클라이언트 요청에 응답하여 제 2 노드에서 발행될 수도 있다.

Description

휴대용 컴퓨팅 디바이스에서 분산 리소스 관리{DISTRIBUTED RESOURCE MANAGEMENT IN A PORTABLE COMPUTING DEVICE}
휴대형 컴퓨팅 디바이스들 ("PCDs") 은 점점 더 인기를 끌고 있다. 이들 디바이스들은 셀룰러 전화기들, 휴대용/개인용 디지털 보조장치("PDA")들, 휴대용 게임 콘솔들, 휴대용 네비게이션 유닛들, 팜탑 컴퓨터들, 및 다른 휴대용 전자 디바이스들을 포함할 수도 있다. 이들 디바이스들 각각은 주요 기능을 가질 수도 있다. 예를 들어, 셀룰러 전화기는 일반적으로 전화 호출들을 수신하고 송신하는 주요 기능을 갖는다.
이러한 디바이스들의 주요 기능에 추가하여, 많은 것들이 부수적 기능들을 포함한다. 예를 들어, 셀룰러 전화기는 위에서 설명된 바와 같이 셀룰러 전화 호출들을 실행하는 주요 기능, 및 스틸 카메라, 비디오 카메라, 글로벌 포지셔닝 시스템 (GPS) 내비게이션, 웹 브라우징, 이메일의 전송 및 수신, 텍스트 메시지들의 전송 및 수신, 푸시-투-토크 능력들 등의 부수적 기능들을 포함할 수도 있다. 이러한 PCD들의 기능성이 증가함에 따라서, 이러한 기능성을 지원하기 위하여 요구되는 컴퓨팅 또는 프로세싱 파워 역시 증가한다. 프로세싱 파워는 PCD 에서 프로세서들의 수를 증가시킴으로써 증가될 수도 있다. 컴퓨팅 파워 및 프로세서들의 수가 증가함에 따라, 프로세서들을 효과적으로 관리할 더 큰 필요성이 존재한다.
전술된 것과 같은 기능들은 리소스들로서 지칭될 수도 있는 다양한 대응하는 하드웨어 및 소프트웨어 엘리먼트에서 구현될 수도 있다. 프로세서는 애플리케이션 프로그램과 같은 소프트웨어의 제어하에 다양한 리소스들을 여러번 요청할 수도 있다. 멀티-프로세서 PCD 에서, 제 1 프로세서는 제 2 프로세서에 의해 제어되는 리소스들과 상이한 리소스들을 제어할 수도 있다. 그러나, 제 1 프로세서가 제 2 프로세서에 의해 제어되는 리소스들을 요청할 수 있는 것이 바람직할 수도 있다.
멀티-프로세서 휴대용 컴퓨팅 디바이스에서 분산 리소스들을 관리하는 방법 및 시스템은 하나의 프로세서가 다른 프로세서에 의해 제어되는 리소스에 대해 리소스 요청을 발행하게 한다. 노드-기반의 소프트웨어 아키텍처를 가지는 휴대용 컴퓨팅 디바이스에서, 리소스는 하나의 노드에 포함될 수도 있다. 예시적인 실시형태에서, 제 1 프로세서에 의해 제어되지만 제 2 프로세서에 의해 제어되는 제 2 노드에 대응하는 제 1 노드가 인스턴스화되고 (instantiated), 그 후에 제 2 노드의 리소스에 간접적으로 액세스하는데 사용된다. 제 1 노드는 분산 노드로 지칭될 수도 있고, 제 2 노드는 네이티브 노드로 지칭될 수도 있다. 제 1 복수의 리소스들은 제 2 프로세서가 아닌 제 1 프로세서에 의해 제어된다. 제 2 복수의 리소스들은 제 1 프로세서가 아닌 제 2 프로세서에 의해 제어된다. 제 1 복수의 리소스들은 제 1 방향성 비순환 그래프에 의해 정의될 수도 있고, 제 2 복수의 리소스들은 제 2 방향성 비순환 그래프에 의해 정의될 수도 있다. 제 1 그래프의 각 노드 또는 리소스는 제 1 프로세서에 의해 제어되는 하나 이상의 리소스들의 기능성의 캡슐화를 나타낸다. 제 1 그래프의 각 에지는 클라이언트 요청을 나타낸다. 제 1 그래프의 인접 노드들은 리소스 의존성들을 나타낸다. 유사하게, 제 2 그래프의 각 노드는 제 2 프로세서에 의해 제어되는 하나 이상의 리소스들의 기능성의 캡슐화를 나타낸다. 제 2 그래프의 각 에지는 클라이언트 요청을 나타낸다. 제 2 그래프의 인접 노드들은 리소스 의존성들을 나타낸다.
예시적인 방법에 따라, 제 1 노드상의 클라이언트 요청은 제 1 프로세서의 제어 하에 클라이언트로부터 수신될 수도 있다. 그 후에, 클라이언트 요청은 제 1 노드상의 클라이언트 요청에 응답하여 제 2 노드에서 발행될 수도 있다.
도면들에 있어서, 동일한 참조부호들은, 달리 나타내지 않으면 다양한 도면들 전반에 걸쳐 동일한 부분들을 지칭한다. "102A" 또는 "102B" 와 같은 문자 지정을 갖는 참조부호들에 있어서, 그 문자 지정은 동일한 도면에 존재하는 2 개의 동일한 부분들 또는 엘리먼트들을 구별할 수도 있다. 참조부호들에 대한 문자 지정은, 참조부호가 모든 도면들에 있어서 동일한 참조부호를 갖는 모든 부분들을 포괄하도록 의도될 경우에 생략될 수도 있다.
도 1 은 휴대용 컴퓨팅 디바이스 ("PCD") 에서 분산 리소스 관리를 위한 시스템의 예시적인 엘리먼트들을 예시하는 기능 블록 다이어그램이다.
도 2 는 제 1 프로세서가 제 2 프로세서에 의해 제어되는 리소스를 요청해야만 하는 인스턴스의 일 실시예를 예시하는 기능 블록 다이어그램이다.
도 3 은 PCD 의 리소스들을 관리하는 노드 아키텍처의 제 1 양태의 다이어그램이다.
도 4 는 PCD 의 예시적인 리소스들의 그룹에 대한 방향성 비순환 리소스 그래프이다.
도 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 는 PCD 의 리소스들을 관리하기 위한 노드 아키텍처를 생성하는 방법을 예시하는 다른 플로우차트이며, 여기서 리소스들 중 일부는 분산 리소스들이다.
도 15 는 PCD 에 대한 소프트웨어 아키텍처에서 분산 리소스에 대한 클라이언트 요청을 생성하는 방법을 예시하는 다른 플로우차트이다.
도 16 은 PCD 에 대한 소프트웨어 아키텍처에서 비-프록시 분산 리소스에 대한 상태 쿼리를 핸들링하는 방법을 예시하는 플로우차트이다.
도 17a 는 PCD 에 대한 소프트웨어 아키텍처에서 비-프록시 분산 리소스에 대한 상태 쿼리를 핸들링하는 방법의 제 1 부분을 예시하는 플로우차트이다.
도 17b 는 PCD 에 대한 소프트웨어 아키텍처에서 비-프록시 분산 리소스에 대한 상태 쿼리를 핸들링하는 방법의 제 2 부분을 예시하는 플로우차트이다.
단어 "예시적인" 은 "일 예, 사례, 또는 예시로서 기능하는 것" 을 의미하도록 본원에서 사용된다. 본원에서 "예시적인" 으로 설명하는 임의의 양태는 반드시 다른 양태들에 비해 바람직하거나 또는 유리한 것으로 해석되지는 않는다.
본 설명에서, 용어 "애플리케이션" 은 또한 오브젝트 코드, 스크립트들, 바이트 코드, 마크업 언어 파일들, 및 패치들과 같은, 실행가능 콘텐츠를 가진 파일들을 포함할 수도 있다. 부가적으로, 본 명세서에서 지칭되는 "애플리케이션" 은 또한, 공개되어야 할 수도 있는 문헌들 또는 액세스되어야하는 다른 데이터 파일들과 같이 본질적으로 실행가능하지 않는 파일들을 포함할 수도 있다.
용어 "콘텐츠" 는 또한 오브젝트 코드, 스크립트들, 바이트 코드, 마크업 언어 파일들, 및 패치들과 같은 실행가능 콘텐츠를 가진 파일들을 포함할 수도 있다. 또한, 본 명세서에서 지칭되는 "콘텐츠"는, 공개되어야 할 수도 있는 문헌들 또는 액세스되어야하는 다른 데이터 파일들과 같이 본질적으로 실행가능하지 않는 파일들을 포함할 수도 있다.
본 명세서에서 사용된 바와 같이, 용어 "컴포넌트", "데이터베이스", "모듈", "시스템" 등은 컴퓨터 관련 엔티티, 즉 하드웨어, 펌웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어, 또는 실행 중인 소프트웨어 중 하나를 가리키는 것으로 의도된다. 예를 들면, 컴포넌트는 프로세서 상에서 실행하는 프로세스, 프로세서, 오브젝트, 실행가능물, 실행 스레드, 프로그램, 및/또는 컴퓨터일 수도 있지만, 이들에 제한되는 것은 아니다. 예시로서, 컴퓨팅 디바이스 상에서 실행하는 애플리케이션 및 컴퓨팅 디바이스 양자는 컴포넌트일 수도 있다. 하나 이상의 컴포넌트들은 프로세스 및/또는 실행 스레드 내에 상주할 수도 있고, 컴포넌트는 하나의 컴퓨터상에 국부화되거나 및/또는 2 이상의 컴퓨터들 사이에 분산될 수도 있다. 또한, 이들 컴포넌트들은 여러 데이터 구조들이 저장된 여러 컴퓨터 판독 가능한 매체로부터 실행할 수도 있다. 컴포넌트들은 로컬 및/또는 원격 프로세스들에 의해, 예컨대, 하나 이상의 데이터 패킷들을 갖는 신호 (예컨대, 로컬 시스템, 분산 시스템에서의 또 다른 컴포넌트와 상호작용하는 하나의 컴포넌트로부터의 데이터 및/또는 그 신호에 의해 다른 시스템들과의 인터넷과 같은 네트워크를 통한 데이터) 에 따라서, 통신할 수도 있다.
본 설명에서, 용어들 "통신 디바이스", "무선 디바이스", "무선 전화기", "무선 통신 디바이스", 및 "무선 핸드셋" 은 상호교환가능하게 사용된다. 제 3 세대 ("3G") 및 제 4 세대 ("4G") 무선 기술의 도래로, 더 큰 대역폭 이용가능성은 아주 다양한 무선 능력들을 갖는 더 휴대성 있는 컴퓨팅 디바이스들을 가능하게 하였다.
본 설명에서, 용어 "휴대용 컴퓨팅 디바이스" ("PCD") 는 배터리와 같은, 제한된 용량의 전원에 동작하는 임의의 디바이스를 기술하는데 사용된다. 배터리 동작식 PCD들이 수십년 동안 사용되고 있었지만, 제 3 세대 ("3G") 및 제 4 세대 ("4G") 무선 기술의 도래와 결합된 재충전가능 배터리들에 있어서의 기술적 진보는 다수의 능력들을 갖는 다수의 PCD들을 가능하게 하였다. 따라서, PCD 는 특히, 셀룰러 전화기, 위성 전화기, 페이저, 개인 휴대정보 단말기 ("PDA"), 스마트폰, 네비게이션 디바이스, 스마트북 또는 리더, 미디어 플레이어, 전술한 디바이스들의 조합, 및 무선 접속을 가진 랩탑 컴퓨터일 수도 있다.
도 1 은 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 방법들 및 시스템들을 구현하는 무선 전화기의 형태의 PCD (100) 의 예시적이고, 비한정적인 양태의 기능 블록 다이어그램이다. 도시된 바와 같이, PCD (100) 는 멀티-코어, 중앙 프로세싱 유닛 ("CPU"; 110A), 그래픽 프로세서 (110B), 및 아날로그 신호 프로세서 (126) 를 갖는 온-칩 시스템 (102) 을 포함한다. 이들 프로세서들 (110A, 110B, 126) 은 당업자들에 알려진 바와 같이, 하나 이상의 시스템 버스들 또는 다른 상호접속 아키텍처들 상에 함께 커플링될 수도 있다.
CPU (110A) 는 당업자에 의해 이해되고 있는 바와 같이, 0 번째 코어 (222), 1 번째 코어 (224), 등등 부터 N 번째 코어 (226) 를 포함할 수도 있다. 대안적인 실시형태들에서, CPU (110A) 및 그래픽 프로세서 (110B) 대신, 하나 이상의 디지털 신호 프로세서들 ("DSPs") 이 또한 당업자에 의해 이해되는 것과 같이 채용될 수도 있다. 추가로, 대안적인 실시형태들에서, 2 이상의 멀티-코어 프로세서들이 포함될 수도 있다.
도 1 에 예시된 바와 같이, 디스플레이 제어기 (128) 및 터치스크린 제어기 (130) 는 멀티코어 CPU (110A) 에 커플링된다. 온-칩 시스템 (102) 외부의 터치스크린 디스플레이 (132) 가 디스플레이 제어기 (128) 및 터치스크린 제어기 (130) 에 커플링된다. 또한 PCD (100) 에는, 비디오 코더/디코더 ("코덱") (134), 예컨대, PAL (phase-alternating line) 인코더, SECAM (sequential couleur avec memoire) 인코더, NTSC (national television system(s) committee) 인코더, 또는 멀티코어 중앙 프로세싱 유닛 ("CPU"; 110A) 에 커플링된, 임의의 다른 유형의 비디오 인코더 (134) 가 포함된다. 비디오 증폭기 (136) 가 비디오 인코더 (134) 및 터치스크린 디스플레이 (132) 에 커플링된다. 비디오 포트 (138) 가 비디오 증폭기 (136) 에 커플링된다. 도 2 에 도시된 바와 같이, 유니버셜 시리얼 버스 ("USB") 제어기 (140) 가 CPU (110A) 에 커플링된다. 또한, USB 포트 (142) 가 USB 제어기 (140) 에 커플링된다. 가입자 식별 모듈 (SIM) 카드 (146) 가 또한 CPU (110A) 에 커플링될 수도 있다. 또한, 도 1 에 도시된 바와 같이, 디지털 카메라 (148) 가 CPU (110A) 에 커플링될 수도 있다. 예시적인 양태에 있어서, 디지털 카메라 (148) 는 전하 결합 디바이스 ("CCD") 카메라 또는 상보적 금속 산화물 반도체 ("CMOS") 카메라이다.
도 1 에 추가로 도시된 바와 같이, 스테레오 오디오 코덱 (150) 이 아날로그 신호 프로세서 (126) 에 커플링될 수도 있다. 더욱이, 오디오 증폭기 (152) 가 스테레오 오디오 코덱 (150) 에 커플링될 수도 있다. 예시적인 양태에 있어서, 제 1 스테레오 스피커 (154) 및 제 2 스테레오 스피커 (156) 가 오디오 증폭기 (152) 에 커플링된다. 도 1 은, 마이크로폰 증폭기 (158) 가 또한 스테레오 오디오 코덱 (150) 에 커플링될 수도 있음을 나타낸다. 부가적으로, 마이크로폰 (160) 이 마이크로폰 증폭기 (158) 에 커플링될 수도 있다. 특정 양태에 있어서, 주파수 변조 ("FM") 무선 튜너 (162) 가 스테레오 오디오 코덱 (150) 에 커플링될 수도 있다. 또한, FM 안테나 (164) 가 FM 무선 튜너 (162) 에 커플링된다. 또한, 스테레오 헤드폰들 (166) 이 스테레오 오디오 코덱 (150) 에 커플링될 수도 있다.
도 1 은 또한, 라디오 주파수 ("RF") 송수신기 (168) 가 아날로그 신호 프로세서 (126) 에 커플링될 수도 있음을 나타낸다. RF 스위치 (170) 가 RF 트랜시버 (168) 및 RF 안테나 (172) 에 커플링될 수도 있다. 도 1 에 도시된 바와 같이, 키패드 (174) 가 아날로그 신호 프로세서 (126) 에 커플링될 수도 있다. 또한, 마이크로폰을 갖는 모노 헤드셋 (176) 이 아날로그 신호 프로세서 (126) 에 커플링될 수도 있다. 또한, 바이브레이터 디바이스 (178) 가 아날로그 신호 프로세서 (126) 에 커플링될 수도 있다. 도 1 은 또한, 전원 (180), 예를 들어 배터리가 온-칩 시스템 (102) 에 커플링되는 것을 나타낸다. 특정 양태에 있어서, 전원 (180) 은 재충전식 배터리 또는 직류 ("DC") 전원을 포함하며, 이들은 AC 전력 소스에 접속되는 교류 ("AC")-DC 트랜스포머로부터 도출된다.
PCD (100) 의 상기 설명된 엘리먼트들 중 일부는 하드웨어를 포함할 수도 있지만, 다른 것들은 소프트웨어를 포함할 수도 있고, 또다른 것들은 하드웨어와 소프트웨어의 조합을 포함할 수도 있다. 용어 "리소스" 는 하드웨어든지, 소프트웨어든지, 또는 이들의 조합이든지, 프로세서에 의해 제어가능한 임의의 그러한 엘리먼트를 지칭하도록 본 명세서에서 사용된다. 리소스는 일 양태에서 그러한 엘리먼트의 기능성의 캡슐화로서 정의될 수도 있다. 달리 나타내어질 수도 있는 경우를 제외하면, 용어 "프로세서" 는 본 명세서에서, CPU (110), 그래픽 프로세서 (110B), 아날로그 신호 프로세서 (126) 와 같은 프로세서를 지칭하거나 소프트웨어, 펌웨어, 또는 유사한 제어 로직의 제어 하에서 동작하는 임의의 다른 프로세서, 제어기 또는 유사한 엘리먼트를 지칭하도록 사용된다.
하기에 더 상세히 설명되는 바와 같이, 리소스의 일 실시예는 프로세서 상에 실행하는 소프트웨어 엘리먼트이다. 예를 들어, 실행하는 애플리케이션 프로그램에 관한 스레드와 같이 프로세서 상의 실행의 스레드는 "요청" 이 리소스에 대해 발행되게 함으로서 리소스에 액세스할 수도 있다. 하기에 설명되는 것과 같이, 리소스 요청들은 본 개시물에서 "프레임워크" 로 지칭되는 소프트웨어-기반의 시스템을 통해 처리된다. 용어 "클라이언트" 는 리소스를 요청하는 기능을 실행하는 엘리먼트를 지칭하기 위해 본 개시물에서 광범위하게 사용된다. 따라서, 용어들이 본 명세서에서 사용될 때, 스레드는 리소스 요청들을 발행하는 목적을 위해 클라이언트를 생성하거나 사용할 수도 있다. 일부 경우들에서, 리소스는, 리소스가 다른 리소스에 대하여 리소스 요청이 발행되게 할 수도 있도록, 클라이언트를 생성하거나 사용할 수도 있음에 유의해야 한다. 하기에서 추가로 설명되는 것과 같이, 그러한 다른 리소스는 요청하는 리소스와 요청받는 리소스 간의 의존성 관계로 인해, 본 명세서에서 "의존적인" 리소스로서 지칭될 수도 있다. 리소스들 및 클라이언트들은 메모리 내의 데이터 구조들에 의해 표시될 수도 있다.
리소스들이 멀티-프로세서 PCD (100) 에서의 특정 프로세서들에 의해 제어되기 때문에, PCD (100) 에서의 모든 프로세서가 PCD (100) 에서의 모든 리소스에 액세스하는 것은 아니다. 도 2 는 PCD (100) 에서의 제 1 프로세서 (202) 가 PCD (100) 에서의 제 2 프로세서 (206) 에 의해 제어되는 리소스 (204) 에 대한 리소스 요청 (203) 을 발행하는데 바람직할 수도 있는 인스턴스의 일 실시예를 예시한다. 제 1 프로세서 (202) 는 또한 복수의 리소스들 (205) 을 제어할 수도 있음을 유의한다. 유사하게, 제 2 프로세서 (206) 는 복수의 추가 리소스들 (207) 을 제어할 수도 있다.
제 1 프로세서 (202) 가 예컨대, 비디오 플레이어 애플리케이션 프로그램과 관련된 스레드 (208) 를 실행중인 경우에, 스레드 (208) 는 제 1 프로세서 (202) 의 성능을 개선하는 제 1 프로세서 (202) 의 하나 이상의 동작 파라미터들의 조정을 요구할 수도 있다. (명확성을 목적으로 스레드 (208) 및 리소스 (204) 가 그들의 개별 프로세서들 (202 및 206) 에 상주하는 것으로 개념적으로 예시되지만, 그러한 엘리먼트들은 널리 이해되는 계산 원리들에 따라 프로세서의 메모리 공간에서 프로세서에 의해 실행되거나, 그렇지 않으면 동작되는 것을 당업자는 이해하고 있다.) 그러한 동작 파라미터들은 예컨대, 클록 속도 및 버스 속도를 포함할 수도 있다. 예를 들어, 다양한 프로세서들은 동일한 버스 클록을 사용할 수도 있지만, 그 프로세서들 중 오직 하나만이 버스 클록의 직접적인 (하드웨어-레벨) 제어를 가질 수도 있다. 클록 속도를 증가시키는 것은, 비디오의 재생이 일반적으로 일부 다른 작업들보다 더 프로세싱 파워 집약적인 작업이기 때문에, 예컨대 비디오 플레이어 애플리케이션 프로그램에 의해 더 양호한 성능을 발생한다. 프로세싱 파워는 일반적으로 초당 수백만 명령 ("MIPS") 으로 표현되기 때문에, 스레드 (208) 는 특정 수의 MIPS 에 대한 호출을 발행할 수도 있다. 전력 관리자 리소스 (204) 는 특정 수의 MIPS 에 대한 요청에 응답하여, 요구되는 MIPS 레벨로 동작하는 제 1 프로세서 (202) 를 촉진시키는 클록 속도, 버스 속도 또는 다른 파라미터들을 표시할 수도 있는 신호들 (210) 에서의 변화들을 발생하는 알고리즘을 포함할 수도 있다.
스레드는, 제 1 프로세서 (202) 가 제 2 프로세서 (206) 와 통신할 수도 있는 버스 또는 프로토콜에 특정한 애플리케이션 프로그램 인터페이스 (API) 를 통해 전력 관리자 리소스 (204) 에 액세스하는 것이 가능할 수도 있다. 그러나, 이하 설명되는 프레임워크는 리소스-특정 및 버스-특정 API 에 비해 리소스 요청들을 핸들링하는 더 균일한 방식을 제공할 수도 있다. 이하 설명되는 것과 같이, 프레임워크를 통해, 리소스 요청들은 그 요청이 리소스 요청이 발행되는 동일한 프로세서에 의해 제어되는 리소스에 대한 것인지 또는 상이한 프로세서에 의해 제어되는 리소스에 대한 것인지 여부에 관계없이 균일한 방식으로 발행되고 서비스된다. 리소스 요청이 발행되는 동일한 프로세서에 의해 제어되는 리소스는 "네이티브" 리소스" 로서 지칭될 수도 있다. 리소스 요청이 발행되는 프로세서 이외의 프로세서에 의해 제어되는 리소스는 본 명세서에서 "원격 리소스" 또는 "분산 리소스" 로서 지칭될 수도 있다.
도 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들 (110) (예컨대, 도 2 참조) 을 포함할 수도 있다.
컴퓨터 명령들의 라이브러리를 포함할 수도 있는 프레임워크 관리자 (440) 는 리소스들의 기능성을 캡슐화하는 노드들을 관리한다. 즉, 노드들은 리소스들에 간접적으로 액세스하도록 액세스될 수도 있다. 편의성을 위해, 리소스의 기능성을 캡슐화하는 노드는 본 명세서에서 리소스를 포함하고, 구성하고, 가지는 등으로 지칭될 수도 있다. 각각의 노드는 하나 이상의 리소스들을 포함할 수도 있다. 노드들은 소프트웨어 코드, 펌웨어, 또는 유사한 매체에서 정의될 수도 있고, 예를 들면, 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 은 또한 일반적으로 두 개의 소프트웨어 엘리먼트들 (448, 450) 의 액션 또는 기능에 대응하는 제 1 클라이언트 (648) 를 예시한다. 도 3 의 예시적인 실시형태에서는, 제 1 클라이언트 (648) 는 일반적으로 휴대용 컴퓨팅 디바이스 (100) 에 의하여 지원되는 특정 애플리케이션 프로그램 모듈 (105) 내에서 발생할 수도 있는 키누름 액션에 대응한다. 그러나, 당업자는 키누름들 이외의 소프트웨어 엘리먼트들의 다른 액션들 및/또는 기능들이 본 개시물의 범위 내에 물론 포함된다는 것을 인식한다. 클라이언트 요청들 (648) 및 그들의 개별 생성에 대한 다른 세부 사항들은 도 11 과 연계하여 이하 설명될 것이다.
도 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) 에서 발생하고 제 2 노드 (622) 로 확장하는 의존성 화살표 (680B) 에 의해 표시되는 것과 같이 제 2 노드 (622) 에 의존한다. 도 3 은 또한 제 1 노드 (602) 가 또한, 의존성 화살표 (680A) 에 의해 예시되는 것과 같이 제 3 노드 (642) 에 의존하는 것을 예시한다. 도 3 은 또한 제 2 노드 (622) 가 의존성 화살표 (680C) 에 의해 예시되는 것과 같이 제 4 노드 (646) 에 의존하는 것을 예시한다. 당업자는, 도 3 의 점선 화살표들로 예시된 의존성들 (680) 이 그 특징이 오직 예시적이며, 개별 노드들 (601) 간의 의존성들의 다른 조합들이 본 개시물의 범위 내에 있는 것을, 인식한다.
프레임워크 관리자 (440) 는 도 3 에 도시된 클라이언트 요청들 (675) 및 의존성들 (680) 을 포함하지만 이에 한정되지는 않는, 전술된 관계들을 유지하는 것을 담당한다. 의존성들과 같은 일부 그러한 관계들은, 리소스들 및 그들의 노드들 (601) 이 PCD (100) 의 소프트웨어 코드에서, 프레임워크 관리자 (440) 가 노드 인스턴스화 프로세스를 시작하기 위해 스타트-업 시간에 액세스한다고 정의되는 방식으로 PCD 스타트-업 시간 (즉, 파워-업, 인스턴스화, 부트-업, 등등) 에 존재한다. 클라이언트 요청들 (675) 과 같은 다른 그러한 관계들은, 예컨대 애플리케이션 프로그램이 리소스를 호출하는 애플리케이션 프로그램 스레드의 실행 동안, 노드들 (601) 이 인스턴스화된 후에 발생한다. 클라이언트 요청들 (675) 이 실행중인 애플리케이션 프로그램 스레드들 또는 노드들 (601) 이외의 유사한 엘리먼트들 (예컨대, 클라이언트 요청 (675A)) 로부터 발생하든지, 또는 노드 (601) 로부터 발생하든지 간에, 클라이언트 요청들 (675) 은 프레임워크 관리자 (440) 를 통해 지향된다. 프레임워크 관리자 (440) 는 노드들 (601) 간의 정보의 전송을 지시한다. 개념적으로, 프레임워크 관리자 (440) 는 다수의 스레드들이 본질적으로 노드들 (601) 과 동시에 통신할 수도 있는 매트릭스로서 기능한다. 상이한 스레드들이 상이한 데이터를 수반할 수도 있기 때문에, 동일한 프레임워크 관리자 소프트웨어 코드는 다수의 스레드들을 서비스할 수도 있다.
이하 더 상세히 설명되는 것과 같이, 프레임워크 관리자 (440) 는 노드의 의존 노드들이 인스턴스화되자마자, 즉 임의의 주어진 노드 (601) 에 대한 의존성들 (680) 이 해결된 경우에 노드 (601) 를 인스턴스화할 수도 있다. 프레임워크 관리자 (440) 는 PCD (100) 의 소프트웨어 아키텍처에서 정의된 모든 노드들 (601) 을 인스턴스화하는 것을 시도한다. 의존성 (680) 은 의존성을 지원하는 리소스가 존재하고 있거나, 또는 의존성 (680) 에 관련된 정보를 핸들링하려고 준비 상태에 있을 경우, 완료되거나 해결된다.
예를 들어, 제 1 노드 (602) 와 제 3 노드 (642) 사이에 존재하는 의존성 관계 (680A) 때문에 단일 리소스 "/clk/cpu" 를 포함하는 제 3 노드 (642) 가 인스턴스화되지 않았다면, 단일 리소스 "/core/cpu" 를 포함하는 제 1 노드 (602) 는 프레임워크 관리자 (440) 에 의해 인스턴스화되지 않을 수도 있다. 일단 제 3 노드 (642) 가 프레임워크 관리자 (440) 에 의해 인스턴스화되었으면, 프레임워크 관리자 (440) 는 의존성 관계 (680A) 때문에 제 2 노드 (602) 를 인스턴스화할 수도 있다.
프레임워크 관리자 (440) 가 특정한 노드 (601) 를, 그의 의존성들 (680) 중 하나 이상이 불완전하거나 미해결되었기 때문에, 인스턴스화할 수 없다면, 프레임워크 관리자 (440) 는 성공적으로 인스턴스화된 그들 노드들 (601) 에 대응하는 단계들을 계속해서 수행하거나 또는 실행할 것이다. 프레임워크 관리자 (440) 는 일반적으로, 의존적인 리소스들이 생성되지 않는 불완전한 의존성들로 인해 존재하지 않을 수도 있는 특정한 노드 (601) 에 대한 호출을 스킵하고, 그 불완전한 상태를 반영하는 메시지들을 그 호출에 리턴할 것이다.
도 1 에 예시된 바와 같은, 멀티-코어 환경에서, 프레임워크 관리자 (440) 는 도 1 의 0 번째, 1 번째 및 N 번째 코어들 (222, 224, 및 226) 과 같은 별개의 코어들 상에서 노드들 (601) 을 생성하거나 또는 인스턴스화할 수도 있다. 노드들 (601) 은 일반적으로, 노드들 (601) 이 서로 의존하지 않는다면, 그리고, 특정한 노드의 대응하는 의존성들 모두가, 이하에서 설명하는 바와 같이, 완전하다면, 멀티-코어 환경에서 별개의 코어들 상에서 그리고 병렬로 생성될 수도 있다. 멀티-프로세서 환경에서, 노드들 (601) 은 도 1 의 CPU (110A), 그래픽 프로세서 (110B), 등과 같은 다양한 프로세서들에서 생성되거나 인스턴스화될 수도 있다. 즉, 일부 노드들 (601) 은 일 프로세서의 메모리 공간에 존재할 수도있는 반면, 다른 노드들 (601) 은 다른 프로세서의 메모리 공간에 존재할 수도 있다. 그러나, 하나의 프로세서 상의 노드들 (601) 이 오직 프레임워크 관리자 (440) 를 통해 다른 프로세서 상의 노드들 (601) 에 액세스할 수 없을 수도 있다는 것에 유의하여야 한다.
전술된 (메인) 프레임워크 관리자 (440) 와 유사한 원격 프레임워크 관리자 (300) 가 프레임워크 관리자 (440) 와 동시에 및 그에 대한 확장물로서 존재할 수도 있다. 원격 프레임워크 관리자 (300) 는 상이한 프로세서들 상의 노드들 (601) 간에 프로세서간 정보 전송들을 조정하기 위해 프레임워크 관리자 (440) 와 협력하거나 함께 작업한다. 즉, 원격 프레임워크 관리자 (300) 는 연관된 노드들 (601) 이 상이한 프로세서들 상에서 존재하는 경우에, 프레임워크 관리자 (400) 가 의존성들 및 클라이언트 요청들과 같은 전술된 관계들을 유지하는 것을 돕는다. 따라서, 노드들 (601) 은 프레임워크 관리자들 (440 및 300) 의 결합 효과를 통해 또다른 프로세서 상의 노드들 (601) 에 액세스가능하게 렌더링되지 않을 수도 있다. 또한, 프레임워크 관리자들 (440 및 300) 의 결합은 연관된 노드들 (601) 이 동일한 프로세서 상에 존재하든지 또는 상이한 프로세서들 상에 존재하든지 간에 본 개시물에서 프레임워크 관리자 (440) 에게 주어진 모든 기능들을 수행할 수도 있다. 그러한 멀티-프로세서 실시형태에서, 프레임워크 관리자들 (300 및 440) 이 포함하는 소프트웨어의 개별 카피들은 프로세서들 각각의 도메인에 상주할 수도 있다. 따라서, 각각의 프로세서는 동일한 프레임워크 관리자 소프트웨어에 액세스한다.
도 4 는 방향성 비순환 그래프 ("DAG"; 400) 의 형태로 전술된 노드들 (602, 622, 642) 을 편리하게 인식한다. 그래프 (400) 는 전술된 소프트웨어 아키텍처를 정의하는 다른 방식이다. 그래프 이론의 어휘에서, 그래프 (400) 의 꼭짓점들은 노드들 (601) 에 대응하고, 그래프 (400) 의 에지들은 클라이언트 요청들 (675) 에 대응하며, 그리고 인접 노드들 또는 꼭짓점들은 리소스 의존성들을 나타낸다. 당업자는, 그래프 (400) 가 의존성들의 결과로서 방향성 그래프이고, 프레임 관리자 (440) 가 사이클이 리소스 (A) 가 리소스 (B) 에 의존하고 리소스 (B) 가 리소스 (A) 에 의존하는 것으로 정의되는 것을 방지하기 때문에 비순환성인 것을, 인식할 것이다. 즉, 프레임워크 관리자 (440) 는 서로 의존적인 것으로 (잘못) 정의된 2 개의 노드들 (601) 을 인스턴스화하지 않을 것이다. 그래프의 비순환적 특성은 이하 설명되는 것과 같이, 각각의 노드 (610) 가 액세스될 경우, (그 노드 (601) 가 거래 프로세싱의 의미에서) 록킹되기 때문에, 데드록들을 방지하는 것이 중요하다. 2 개의 노드들 (601) 이, 제 1 스레드가 이들 2 개의 노드들 (601) 중 하나에 액세스하고 록킹하기 위한 것인 동시에 제 2 스레드가 이들 2 개의 노드들 (601) 중 다른 하나에 액세스하고 록킹하기 위한 것인 경우, 서로 의존하였다면, 양자의 스레드들은 고정될 것이다. 그러나, 소프트웨어 개발자 또는 소프트웨어 아키텍처를 정의하는 것과 연관된 다른 사람이 소프트웨어 아키텍처에서 서로 의존하는 2 개의 리소스들을 정의하는 것이 바람직하다고 간주하는 상대적으로 드문 경우에, 2 개 (또는 그 이상) 의 리소스들이 서로 동일한 노드 (601) 에 포함될 수도 있다. 동일한 노드에서 2 개의 리소스들은 동일한 로크 상태를 공유할 것이다. 그것은 소프트웨어 개발자 또는 다른 그러한 사람이 아키텍처에서 노드 (622) 와 같은 복수형-리소스 노드를 정의할 것을 선택할 수도 있다는 이유에 적어도 부분적으로 기초한다.
본 개시물은 명확성과 편리함을 위해, 노드 (601) 의 "리소스" 보다 "노드" (601) 를 참조하지만, 클라이언트 요청들은 노드들보다는 특정 리소스들에 관련될 수도 있다는 것이 이해되어야 한다. 다시 말해서, 하나 이상의 리소스들의 기능성을 캡슐화하는 데이터 구조일 수도 있는, 전술된 것과 같은 노드 (601) 는 다른 노드 (601) 와 같은 클라이언트 요청의 클라이언트 또는 다른 발행자의 관점에서 투명할 수도 있다. 클라이언트의 관점에서, 요청은 노드보다는 리소스에 대하여 발행된다. 유사하게, 클라이언트의 관점에서, 상태 쿼리, 이벤트, 또는 아키텍처의 다른 엘리먼트는 노드보다는 리소스와 연관된다.
예시적인 그래프 (400) 와 같은 리소스 그래프는 도 6 내지 도 10 과 관련하여 이하 설명되는, 의존성들에 따른 노드들 (601) 의 인스턴스화를 이해하는데 유용하다. 노드들 (642 및 646) 과 같은 리프 노드들은, 리프 노드들이 어떤 의존성도 가지지 않기 때문에, 비-리프 노드들 이전에 인스턴스화된다. 일반적으로, 노드 (601) 는 그 노드에 의존하는 노드가 인스턴스화될 수도 있기 전에 인스턴스화되어야만 한다. 추가로, 리소스 요청을 서비스하는 것은, 꼭지점들이 노드들 (601) 에 대응하고, 에지들이 클라이언트 요청들 (675) 에 대응하고, 인접 노드들 또는 꼭짓점들이 리소스 의존성들을 나타내는 방향성 비순환 그래프를 가로지르는 것에 대응하는 것으로 보여질 수 있다.
멀티-프로세서 PCD (100) 에서, 제 1 프로세서는 제 1 리소스 그래프에서 제 1 세트의 노드들 (601) 에 액세스하거나 이들을 제어할 수도 있는 반면, 제 2 프로세서는 제 2 리소스 그래프에서 제 2 세트의 노드들 (601) 에 액세스하거나 이들을 제어할 수도 있으며, 여기서 제 1 및 제 2 리소스 그래프들은 임의의 리소스들을 공유하지 않는다, 즉 이들은 상호 배타적인 리소스 그래프들이다. 즉, 그러한 환경에서, 각각의 프로세서는 다른 프로세서들에 액세스할 수 없는 다른 엘리먼트들 및 리소스들 사이의 관계들을 정의하는 자기 소유의 리소스 그래프를 갖는다. 본 개시물의 분산 리소스 관리는, 2 이상의 프로세서들이 각각 그들 소유의 리소스 그래프들에서의 리소스들에 액세스하고 다른 프로세서의 리소스 그래프들에서의 리소스들에 액세스하지 않는 경우에, 전술된 관계들, 예컨대 의존성들 및 클라이언트 요청들을 유지하는 것과 관련된다.
리소스들로의 액세스에 대한 앞서 참조된 제한은, 일부 실시형태들에서 하드웨어 구성에 의해 제한될 수도 있다. 즉, 프로세서는 레지스터와 같은 하드웨어 디바이스에 영향을 줄 수 있는 어떤 수단도 가지지 않을 수도 있는데, 이는 하드웨어 디바이스가 다른 프로세서에 의해 제어되거나 다른 프로세서의 메모리 공간 내에 있기 때문이다. 대안적으로 또는 부가적으로, 리소스들에 액세스하는 것에 대한 제한은 보안 위험들 (예컨대, 다른 프로세서를 감염시키고 있을 수도 있는 바이러스) 에 대한 프로세서의 노출을 최소화하는 것과 같은 이유들로 소프트웨어에 부과될 수도 있다.
도 5 는 도 1 의 PCD (100) 의 리소스들을 관리하는 시스템에 대한 소프트웨어 아키텍처 (500B1) 의 다른 양태의 일반적인 다이어그램이다. 이러한 양태는 연관되는 모든 리소스들 및 다른 엘리먼트들이 동일한 프로세서에 의해 제어되는, 즉 그들이 동일한 리소스 그래프에 포함되는 아키텍처 및 PCD (100) 의 문맥에서 명확성을 위해 설명된다. 이러한 일반적인 다이어그램에서, 각각의 노드 (601) 의 하나 이상의 리소스들에는 고유한 명칭들이 제공되지 않았다. 도 5 의 노드 또는 리소스 그래프 (500B1) 는 단지 노드들 (601), 클라이언트들 (648), 이벤트들 (690), 및 아키텍처 또는 프레임워크 관리자 (440) 에 의해 지원되는 쿼리 기능들 (695) 을 포함한다. 각각의 노드 (601) 는 계란형 형상으로, 그리고 노드 (601) 내의 리소스들 사이의 각각의 의존성들을 나타내는 특정의 방향들을 가진 화살표들 (680) 로 예시되어 있다.
도 5 는 또한 어떻게 제 1 노드 (601A) 의 클라이언트 (648) 가 클라이언트 요청 (675) 을 제 1 노드 (601A) 로 발행할 수도 있는지를 예시한다. 이들 클라이언트 요청들 (675) 이 발행된 후, 제 2 노드 (601B) 는 이벤트 (690) 를 트리거하거나 또는 쿼리 (695) 에 대한 응답을 제공할 수도 있으며, 여기서, 이벤트 (690) 및 쿼리 (695) 에 대응하는 메시지들이 클라이언트 (648) 로 다시 돌아간다.
도 6 은 도 1 의 PCD (100) 의 리소스들을 관리하는 시스템을 위한 소프트웨어 아키텍처 (500B2) 의 전술된 양태의 더 구체적인 다이어그램이다. 도 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) 에 의해 관리되는 각각의 엘리먼트들 사이의 관계들을 식별하는데, 그리고 소프트웨어 팀에 의한 분쟁 중재에 유용한 툴로서 프레임워크 관리자 (440) 에 의해 자동적으로 발생될 수 있다.
도 7 은 PCD (100) 의 리소스(들)을 관리하는 소프트웨어 구조들을 생성하거나 인스턴스화하는 방법 (1000A) 을 예시하는 플로우차트이다. 이러한 방법은 연관되는 모든 리소스들 및 다른 엘리먼트들이 동일한 프로세서에 의해 제어되는, 즉 그들이 동일한 리소스 그래프에 포함되는 아키텍처의 문맥에서 명확성을 위해 설명된다. 블록 (1005) 은 PCD (100) 의 리소스들을 관리하는 방법 또는 프로세스 (1000) 의 제 1 루틴이다. 블록 (1005) 에서, 루틴은 노드 구조 데이터를 수신하기 위해 프레임워크 관리자 (440) 에 의해 실행되거나 수행될 수도 있다. 노드 구조 데이터는 특정한 노드 (601) 가 다른 노드들 (601) 과 가질 수도 있는 의존성들을 약술하는 의존성 어레이를 포함할 수도 있다. 노드 구조 데이터 및 이 루틴 또는 서브방법 (705) 에 관한 추가적인 세부 사항들은 도 9 와 관련하여 아래에서 자세히 설명될 것이다.
다음으로, 블록 (1010) 에서, 프레임워크 관리자 (440) 는 블록 (1005) 에서 수신된 노드 구조 데이터의 부분인 의존성 데이터를 검토할 수도 있다. 결정 블록 (1015) 에서, 프레임워크 관리자 (440) 는 노드 구조 데이터가 리프 노드 (601) 를 정의하는지 여부를 결정할 수도 있다. 리프 노드 (601) 는 일반적으로 노드 구조 데이터에 기초하여 생성될 노드가 도 3 및 도 4 의 노드들 (642 및 646) 과 같이 어떤 의존성들도 갖지 않는다는 것을 의미한다. 결정 블록 (1015) 에 대한 문의 (inquiry) 가 긍정이면, 현재의 노드를 생성하기 위한 노드 구조 데이터가 임의의 의존성들을 갖지 않는다는 것을 의미하며, 프레임워크 관리자 (440) 는 루틴 블록 (1025) 으로 계속된다.
결정 블록 (1015) 에 대한 문의가 부정이면, "아니오" 브랜치에 뒤이어서 결정 블록 (1020) 이 뒤따르며, 여기서, 프레임워크 관리자는 노드 구조 데이터 내에 모두 강한 (hard) 의존성들이 존재하는지 여부를 결정한다. 강한 의존성은 리소스가 그것 없이 존재할 수 없는 의존성을 포함할 수도 있다. 한편, 약한 (soft) 의존성은 리소스가 옵션의 단계로서 의존적인 리소스를 사용할 수도 있는 의존성을 포함할 수도 있다. 약한 의존성은, 약한 의존성이 존재하지 않을 때에도, 약한 의존성을 갖는 노드 (601) 또는 노드 (601) 의 리소스가 노드 아키텍처 내에서 생성되거나 또는 인스턴스화될 수도 있다는 것을 의미한다.
약한 의존성의 일 예는 다수의 리소스들을 포함하는 리소스 지향 노드 (601) 에 대한 동작에 중요하지 않은 최적화 특성을 포함할 수도 있다. 프레임워크 관리자 (440) 는 약한 의존성이 생성되지 않은 약한 의존성들을 가지는 그들 노드들 또는 리소스들에 대해서 존재하지 않을지라도 존재하는 모든 강한 의존성들에 대해 노드 또는 리소스를 생성하거나 또는 인스턴스화할 수도 있다. 콜 백 특성은, 약한 의존성이 프레임워크 관리자 (440) 에 이용가능하게 될 때, 프레임워크 관리자 (440) 가 약한 의존성을 참조하는 각각의 콜백에게 약한 의존성들이 현재 이용할 수 있다고 통지할 수 있도록, 약한 의존성을 참조하는데 사용될 수도 있다.
결정 블록 (1020) 에 대한 문의가 부정이면, "아니오" 브랜치에 이어서 블록 (1027) 이 뒤따르며, 여기서, 노드 구조 데이터는 메모리와 같은 임시 스토리지에 프레임워크 관리자 (440) 에 의해 저장되며, 프레임워크 관리자 (440) 는 이러한 비-인스턴스화된 노드와 연관된 콜 백 특성을 생성한다.
결정 블록 (1015) 에 대한 문의가 긍정이면, "예" 브랜치에 이어서 루틴 (1025) 이 뒤따르며, 여기서, 노드 (601) 는 루틴 블록 (1005) 에서 수신된 노드 구조 데이터에 기초하여 생성되거나 또는 인스턴스화된다. 루틴 블록 (1025) 의 추가의 상세들은 도 9 과 관련하여 하기에 설명될 것이다. 다음으로, 블록 (1030) 에서, 프레임워크 관리자 (440) 는, 다른 노드들 (601) 이 정보를 새로 생성된 노드 (601) 로 전송하거나 그로부터 정보를 수신할 수 있도록, 새로 생성된 노드 (601) 를 그의 고유한 리소스 명칭(들)을 이용하여 공표한다.
지금부터 도 7 의 연속 플로우 차트인 도 8 을 참조하면, 블록 (1035) 에서, 프레임워크 관리자 (440) 는 새로 생성된 노드 (601) 에 의존하는 다른 노드들 (601) 에게, 새로 생성된 노드 (601) 가 인스턴스화되어 있고 정보를 수신하거나 또는 송신할 준비가 되어 있다고 통지한다. 하나의 예시적인 양태에 따르면, 통지들은 의존 노드가, 도 5 의 노드 (601B) 와 유사하게, 생성될 때 즉시 트리거된다, 즉, 통지들은 회귀적으로 수행된다. 따라서, 도 5 의 노드 (601B) 가 구성되면, 노드 (601A) 가 즉시 통지받는다. 이 통지는 (노드 (601B) 가 노드 (601A) 의 최종 의존성이었기 때문에) 노드 (601A) 가 구성되도록 할 수도 있다. 노드 (601B) 의 구성은 다른 노드들 (601) 로 하여금 통지받는 등등을 할 수 있게 할 수도 있다. 노드 (601B) 는 노드 (601B) 에 의존하는 최종 리소스가 완료될 때까지 완료되지 않는다.
약간 더 복잡한, 제 2 구현예는 통지들의 모두를 별개의 통지 큐 상에 할당한 후, 단일 시점에서 시작하는 큐를 통해서 실행하는 것이다, 즉, 통지들이 반복하여 수행된다. 따라서 도 5 의 노드 (601B) 가 구성될 때, 노드 (601A) 로의 통지가 리스트 상으로 푸시된다. 그 후, 그 리스트가 실행되며, 노드 (601A) 가 통지를 받는다. 이것은 다른 추가적인 노드들 (601) (노드 (601A) 에 더해서, 도 5 에는 예시되지 않음) 로의 통지가 동일한 리스트 상에 할당되게 하며, 그 후 노드 (601A) 로의 통지가 전송된 후에 그 통지가 전송된다. 노드 (601B) 및 노드 (601A) 와 연관된 모든 작업이 완료되기 이후까지, 다른 노드들 (601) 로의 통지들 (노드 (601A) 로의 통지에 더해) 이 일어나지 않는다.
논리적으로, 이들 2 개의 구현예들은 동등하나, 구현될 때 상이한 메모리 소비 특성들을 갖는다. 귀납적인 실현은 간단하지만 임의의 양의 스택 공간을 소비할 수 있으며, 이때 스택 소비는 의존성 그래프의 깊이 (depth) 의 함수이다. 반복 구현예는 약간 더 복잡하며 조금 더 많은 정적 메모리 (통지 리스트) 를 필요로 하지만, 스택 사용량은 도 5 에 예시된 것과 같은 의존성 그래프의 깊이와 관계없이, 일정하다.
또한, 블록 (1035) 에서의 노드 생성의 통지는 다른 노드들에 한정되지 않는다. 또한, 이는 별칭 구성을 위해 내부적으로 사용될 수도 있다. 시스템 (500A) 에서의 임의의 엘리먼트는 동일한 메커니즘을 이용하여, 단지 다른 노드들이 아닌, 노드가 이용가능하게 될 때 통지를 요청할 수도 있다. 노드들 및 비-노드들 양자는 동일한 통지 메커니즘을 이용할 수도 있다.
결정 블록 (1040) 에서, 프레임워크 관리자 (440) 는 다른 노드들 (601) 또는 약한 의존성들이 현재의 노드 (601) 의 생성에 기초한 생성 또는 인스턴스화를 위해 현재 해제되어 있는지 여부를 결정한다. 결정 블록 (1040) 은, 일반적으로, 특정 의존성 관계들 (680) 이 생성 또는 인스턴스화를 최근에 겪은 현재 노드에 의해 수행되었기 때문에, 리소스들이 생성될 수도 있는지 여부를 결정한다.
결정 블록 (1040) 에 대한 문의가 긍정이면, "예" 브랜치에 이어서 루틴 블록 (1025) 이 뒤따르며, 여기서, 막 생성된 노드 (601) 에 의한 의존성의 충족 때문에 해제된 노드 (601) 가 이제 생성되거나 또는 인스턴스화될 수도 있다.
결정 블록 (1040) 에 대한 문의가 부정이면, "아니오" 브랜치에 이어서 블록 (1045) 이 뒤따르며, 여기서, 프레임 작업 관리자 (440) 는 도 2 에 예시된 바와 같이, 소프트웨어 아키텍처의 엘리먼트들 사이의 통신들을 관리할 수도 있다. 다음으로, 블록 (1050) 에서, 프레임워크 관리자 (440) 는 특정한 리소스와 연관된 리소스 명칭들을 이용함으로써 리소스들에 의해 취해진 액션들을 계속해서 로깅하거나 또는 기록할 수도 있다. 블록 (1045) 은 프레임워크 관리자 (440) 또는, 리소스들, 노드들 (601), 클라이언트들 (648), 이벤트들 (695), 및 쿼리 기능들 (697) 과 같이 프레임워크 관리자 (440) 에 의해 관리되는 임의의 엘리먼트에 의해 취해지는 임의의 액션 이후, 프레임워크 관리자 (440) 에 의해 실행될 수도 있다. 블록 (1045) 은 프레임워크 관리자 (440) 가 노드 (601) 의 리소스와 같은 특정한 엘리먼트를 생성한 저작자들 (authors) 에 의해 제공되는 그들의 고유 식별자 또는 명칭에 따라서 각각의 엘리먼트에 의해 수행되는 액션들을 리스트하는 활동의 실행 로그 (running log) 를 유지할 수도 있는 노드 아키텍처의 또 다른 양태를 나타낸다.
종래기술에 비해, 블록 (1050) 에서, 시스템의 각각의 리소스에 할당된 고유한 명칭들을 리스트하는 활동의 로깅은 고유하며, 디버깅 및 에러 트러블슈팅 (error troubleshooting) 에서 사용되는 것과 같은 현저한 이점들을 제공할 수도 있다. 노드 아키텍처 (500A) 의 또 다른 고유한 양태는, 별개의 팀들이 상이한 하드웨어 및/또는 소프트웨어 엘리먼트들 상에서, 서로 독립적으로, 작업할 수도 있다는 것이며, 여기서, 각각의 팀은 다른 팀들 및/또는 OEM (original equipment manufacturer) 에 의해 할당된, 덜 의미 있고 그리고 대개 혼란시키는 리소스 명칭들을 변환하기 위해 테이블들을 생성할 필요 없이, 고유하며 추적하는데 용이한 리소스 명칭들을 사용할 수 있을 것이다.
다음으로, 결정 블록 (1055) 에서, 프레임워크 관리자 (440) 는 프레임워크 관리자 (440) 에 의해 기록된 활동의 로그가 요청되었는지 여부를 결정한다. 결정 블록 (1055) 에 대한 문의가 부정이면, "아니오" 브랜치에 이어서 프로세스의 종료가 뒤따르며, 여기서, 프로세스는 루틴 (1005) 으로 리턴한다. 결정 블록 (1055) 에 대한 문의가 긍정이면, "예" 브랜치에 이어서 블록 (1060) 이 뒤따르며, 여기서, 프레임워크 관리자 (440) 는 의미 있는 리소스 명칭들 및 그 리소스 명칭들에 의해 수행되는 각각의 액션들을 포함하는 활동 로그를, 프린터 또는 디스플레이 스크린 및/또는 양자와 같은 출력 디바이스로 전송한다. 프로세스는 그 후 전술된 루틴 블록 (1005) 으로 리턴한다.
도 9 는 PCD (100) 의 소프트웨어 아키텍처를 정의하는 노드 구조 데이터를 수신하는 도 7 의 서브-방법 또는 루틴 (1005) 을 예시하는 플로우차트이다. 수신 방법은 예컨대, PCD (100) 가 스타트업 또는 초기화될 경우와 같은 임의의 적절한 시간에 발생할 수도 있다. 그러한 인스턴스에서, 노드 구조 데이터는 프로세서가 아키텍처에 따라 노드들 (601) 을 인스턴스화하기 위한 준비로 메모리로부터 대응하는 소프트웨어 코드를 판독할 경우, 수신된다. 블록 (1105) 은 도 7 의 서브 방법 또는 루틴 (1005) 에서 제 1 단계이다. 블록 (1105) 에서, 프레임워크 관리자 (440) 는 소프트웨어 또는 하드웨어 엘리먼트, 예컨대 도 7 의 CPU (110) 및 클록 (442) 에 대한 고유한 명칭을 수신할 수도 있다. 전술한 바와 같이, 노드 (601) 는 적어도 하나의 리소스를 참조해야 한다. 각각의 리소스는 시스템 (500A) 에서 고유한 명칭을 갖는다. 시스템 (500A) 내 각각의 엘리먼트는 고유한 명칭으로 식별될 수도 있다. 각각의 엘리먼트는 문자 관점 (character perspective) 에서 고유한 명칭을 갖는다. 즉, 일반적으로, 시스템 (500A) 내에 동일한 명칭을 갖는 어떤 2 개의 엘리먼트들도 존재하지 않는다. 시스템의 예시적인 양태들에 따르면, 노드들 (601) 의 리소스들은 일반적으로 시스템 전반에 걸쳐서 고유한 명칭들을 가질 수도 있으며, 그러나, 클라이언트 또는 이벤트 명칭들이, 원하는 바에 따라 고유할 수도 있지만, 고유할 것을 필요로 하지는 않는다.
편의를 위해, 고유한 명칭들을 생성하기 위해 순방향 슬래시 "/" 문자들을 채용하는 종래의 트리 파일 명명 (naming) 구조 또는 파일 명명 "메타포" 가 예컨대, CPU (110) 에 대해 "/core/cpu" 및 클록 (442) 에 대해 "/clk/cpu" 과 같이, 채용될 수도 있지만 이에 한정되지 않는다. 그러나, 당업자에게 인식되는 바와 같이, 영숫자 문자들 및/또는 심볼들의 임의의 다른 조합을 포함하는 다른 타입의 리소스 명칭들이 본 개시물의 범위 내에 물론 포함된다.
다음으로, 블록 (1110) 에서, 프레임워크 관리자 (440) 는 생성되고 있는 노드 (601) 의 하나 이상의 리소스들과 연관된 하나 이상의 드라이버 기능들에 대한 데이터를 수신할 수도 있다. 드라이버 기능은 일반적으로 특정한 노드 (601) 에 대한 하나 이상의 리소스들에 의해 완료되는 액션을 포함한다. 예를 들어, 도 7a 및 도 7b 에서, 노드 (602) 의 리소스 /core/cpu 에 대한 드라이버 기능은 요청된 프로세싱의 요청된 양을 제공하기 위해 필요로 하는 버스 대역폭의 양 및 CPU 클록 주파수를 요청할 수도 있다. 이들 요청들은 노드들 (642) 및 노드 (622) 에서 리소스들의 클라이언트들을 통해서 이루어질 것이다. 노드 (642) 에서의 /clk/cpu 에 대한 드라이버 기능은 노드 (602) 의 /core/cpu 리소스로부터 수신된 요청에 따라서 물리적인 클록 주파수를 실제로 설정하는 것을 대개 담당할 것이다.
블록 (1115) 에서, 프레임워크 관리자 (440) 는 노드 속성 데이터를 수신할 수도 있다. 노드 속성 데이터는 (노드가 사용자 공간 애플리케이션들을 통해서 액세스될 수 있는) 보안성, (노드가 시스템 내 다른 프로세서들로부터 액세스될 수 있는) 원격성 (remotability), 및 (리소스가 다수의 병행 클라이언트들을 지원할 수 있는) 접근성과 같은, 노드 정책들을 정의하는 데이터를 포함한다. 프레임워크 관리자 (440) 는 또한 리소스로 하여금, 요청 평가 또는 로깅 정책과 같은, 디폴트 프레임워크 거동을 오버라이딩하게 하는 속성들을 정의할 수도 있다.
후속하여, 블록 (1120) 에서, 프레임워크 관리자 (440) 는 생성중인 특정한 노드 (601) 에 대한 커스터마이징된 사용자 데이터를 수신할 수도 있다. 사용자 데이터는 "C" 프로그래밍 언어에 대해 당업자가 주지하고 있는 바와 같이, 보이드 (void) "star" 필드를 포함할 수도 있다. 사용자 데이터는 또한 "trust me" 필드로서 당업자에게 알려져 있다. 예시적인 커스터마이징된 사용자 데이터는 주파수 테이블들, 레지스터 맵들 등과 같은, 테이블들을 포함할 수도 있지만 이에 한정되지 않는다. 블록 (1120) 에서 수신된 사용자 데이터는, 커스터마이제이션이 프레임워크 관리자 (440) 에 의해 인식되거나 또는 전적으로 지원되지 않으면, 시스템 (500A) 에 의해 참조되지 않으나, 리소스의 커스터마이제이션을 고려한다. 이 사용자 데이터 구조는 특정한 또는 구체적인 사용들을 위해 확장시키려고 의도된 "C" 프로그래밍 언어에서 베이스 클래스이다.
당업자는 특정 클래스의 구체적인 사용들을 확장하는 다른 종류의 데이터 구조들도 본 개시물의 범위 내에 있음을 인식한다. 예를 들어, "C++" (C-플러스-플러스) 의 프로그래밍 언어에서, 등가 구조는 노드 (601) 내 리소스에 대해 확장 메커니즘이 될 키워드 "public" 을 포함할 수도 있다.
다음으로, 블록 (1125) 에서, 프레임워크 관리자 (440) 는 의존성 어레이 데이터를 수신할 수도 있다. 의존성 어레이 데이터는 생성중인 노드 (601) 가 의존하는 하나 이상의 리소스들 (601) 의 고유한 및 구체적인 명칭들을 포함할 수도 있다. 예를 들어, 도 6 의 제 1 노드 (602) 가 생성중이었다면, 이 블록 (1125) 에서, 의존성 어레이 데이터는 제 1 노드 (602) 가 의존하는, 제 2 노드 (622) 의 3개의 리소스들의 리소스 명칭들 및 제 3 노드 (642) 의 단일 리소스 명칭을 포함할 수도 있다.
다음으로, 블록 (1130) 에서, 프레임워크 관리자 (440) 는 리소스 어레이 데이터를 수신할 수도 있다. 리소스 어레이 데이터는 제 1 노드 (602) 가 생성중이었다면, 도 7b 및 도 7c 의 제 1 노드 (602) 에 관련된 파라미터들과 같은, 생성중인 현재의 노드에 대한 파라미터들을 포함할 수도 있다. 리소스 어레이 데이터는 다음 데이터 중 하나 이상을 포함할 수도 있다: 다른 리소스들의 명칭들; 유닛; 최대값; 리소스 속성들; 플러그-인 데이터; 및 블록 (1120) 의 커스터마이즈 사용자 데이터와 유사한 임의의 커스터마이징된 리소스 데이터. 플러그-인 데이터는 일반적으로 소프트웨어 라이브러리로부터 취출된 기능들을 식별하고, 생성중인 특정한 노드 또는 복수의 노드들에 의해 지원될 수도 있는 클라이언트 유형들을 일반적으로 리스트한다. 플러그인 데이터는 또한 클라이언트 생성 및 파괴의 커스터마이제이션을 고려한다. 블록 (1130) 이후, 프로세스는 도 7 의 블록 (1010) 으로 리턴한다.
도 9 에서, 속성 데이터 블록 (1115), 커스터마이징된 사용자 데이터 블록 (1120), 및 의존성 어레이 데이터 블록 (1125) 은 이들 특정한 단계들이 옵션적이며 임의의 주어진 노드 (601) 에 대해 요구되지 않는다는 것을 나타내기 위해 파선들로 예시되어 있다. 한편, 고유한 명칭 블록 (1105), 드라이버 기능 블록 (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) 은 루틴 블록 (1205) 의 제 1 단계이며, 여기서, 하나 이상의 리소스들 (601) 의 클라이언트 (648) 가 생성된다. 블록 (1205) 에서, 프레임워크 관리자 (440) 는 생성중인 클라이언트 (648) 에 할당된 명칭을 수신한다. 리소스 명칭들과 유사하게, 클라이언트 (648) 에 대한 명칭은 임의 종류의 영숫자 및/또는 심볼들을 포함할 수도 있다.
다음으로, 블록 (1310) 에서, 커스터마이징된 사용자 데이터는 생성중인 클라이언트 (648) 에 대해 임의의 특정한 커스터마이제이션들이 있으면, 프레임워크 관리자 (440) 에 의해 수신될 수도 있다. 블록 (1310) 은 단계가 옵션적임을 나타내기 위해 파선들로 예시되어 있다. 블록 (1310) 의 커스터마이징된 사용자 데이터는 노드들 (601) 에 대한 리소스들의 생성과 관련하여 전술된 커스터마이징된 사용자 데이터와 유사하다.
블록 (1315) 에서, 프레임워크 관리자 (440) 는 생성중인 특정한 클라이언트에 할당된 클라이언트 타입 카테고리를 수신한다. 현재 기록중인 클라이언트 타입 카테고리는 다음 4 개의 타입들 중 하나를 포함할 수도 있다: (a) 요구형 (required), (b) 임펄스, (c) 벡터, 및 (d) 등시성 (isochronous). 클라이언트 타입 카테고리 리스트는 시스템 (101) 에 의해 관리중인 리소스들에, 그리고, 노드들 (601) 의 리소스들에 의존하는 애플리케이션 프로그램들에 의존하여 확장될 수도 있다.
요구형 카테고리는 일반적으로 그 요구된 클라이언트 (648) 로부터 특정한 리소스 (601) 로 전달되는 스칼라 값의 프로세싱에 대응한다. 예를 들어, 요구된 요청은 특정수의 MIPs (millions of instructions per second) 를 포함할 수도 있다. 한편, 임펄스 카테고리는 일반적으로 시작 시간 또는 정지 시간의 임의의 지정 없이, 어떤 시간 기간 내에 일부 활동을 완료하라는 요청의 프로세싱에 대응한다.
등시성 카테고리는 일반적으로 재발생하고 있고, 잘-정의된 시작 시간 및 잘-정의된 종료 시간을 갖는 액션에 대한 요청에 대응한다. 벡터 카테고리는 일반적으로 직렬로 또는 병렬로 요구되는 다수의 액션들의 부분인 데이터의 어레이에 대응한다.
후속하여, 블록 (1320) 에서, 프레임워크 관리자 (440) 는 클라이언트 (648) 가 동기적으로 또는 비동기적으로 지정되어 있는지 여부를 나타내는 데이터를 수신한다. 동기적 클라이언트 (648) 는 프레임워크 관리자 (440) 에게, 리소스 (601) 가 동기적 클라이언트 (648) 로부터의 그 요청된 작업을 완료하는 것을 종료하였다는 데이터 및 표시를 리턴할 때까지, 노드 (601) 의 리소스를 록킹할 것을 일반적으로 요구하는 클라이언트이다.
다른 한편, 비동기적 클라이언트 (648) 는 프레임워크 관리자 (440) 에 의해 액세스되는 하나 이상의 스레드들에 의해 병렬로 핸들링될 수도 있다. 프레임워크 (440) 는 스레드에 대한 콜백을 생성할 수도 있으며, 콜백이 각각의 스레드에 의해 실행되었을 때 값을 리턴할 수도 있다. 당업자는 비동기적 클라이언트 (648) 의 작업이 실행되고 있을 경우, 비동기적 클라이언트 (648) 가 동기적 클라이언트 (648) 가 실행하는 것과 유사하게 리소스들을 록킹하지 않는 것을 인식한다.
블록 (1320) 이후, 결정 블록 (1325) 에서, 프레임워크 관리자 (440) 는 클라이언트 (645) 에 의해 식별되는 리소스가 이용가능한 지를 결정한다. 결정 블록 (1325) 에 대한 문의가 부정이면, "아니오" 브랜치에 이어서 블록 (1330) 이 뒤따르며, 여기서, 클라이언트 (648) 가 이때에 생성될 수 없다는 것을 나타내는 널 값 또는 메시지가 사용자에게 리턴된다.
결정 블록 (1325) 에 대한 문의가 긍정이면, "예" 브랜치에 이어서 결정 블록 (1335) 이 뒤따르며, 여기서, 프레임워크 관리자 (440) 는 클라이언트 (648) 에 의해 식별되는 각각의 리소스가 블록 (1310) 에서 제공된 클라이언트 타입을 지원하는지 여부를 결정한다. 결정 블록 (1335) 에 대한 문의가 부정이면, "아니오" 브랜치에 이어서 블록 (1330) 이 뒤따르며, 여기서, 클라이언트 (648) 가 이때에 생성될 수 없다는 것을 나타내는 널 값 또는 메시지가 리턴된다.
결정 블록 (1335) 에 대한 문의가 긍정이면, "예" 브랜치에 이어서 블록 (1340) 이 뒤따르며, 여기서, 프레임워크 관리자 (440) 는 메모리에서 클라이언트 (648) 를 생성하거나 또는 인스턴스화한다. 다음으로, 블록 (1345) 에서, 옵션적 인수들과 같은, 임의의 커스터마이징된 사용자 데이터가 블록 (1310) 에서 수신되면, 이러한 옵션적 인수들은 그들 각각의 리소스들과 함께 특정한 노드들 (601) 로 맵핑될 수도 있다. 다음으로, 블록 (1350) 에서, 새로 생성된 클라이언트 (645) 가 전술된 것과 같은 유휴 상태에서 또는 요청된 상태에서 그의 대응하는 하나 이상의 리소스들에 커플링된다. 프로세스는 그 후 도 10 의 단계 (1210) 로 리턴한다.
도 12 는 PCD (100) 에 대한 소프트웨어 아키텍처에서 리소스 (601) 에 대한 클라이언트 요청 (675) 을 생성하는 방법 (1400) 을 예시하는 플로우차트이다. 방법 (1400) 은 일반적으로 도 7 내지 도 11 과 관련하여 전술된 것과 같이 클라이언트 및 노드 생성 (인스턴스화) 이후 실행된다.
블록 (1405) 은 리소스 (601) 에 대한 클라이언트 요청 (675) 을 생성하는 방법 (1400) 의 제 1 단계이다. 이 방법 (1400) 은 어떻게 다음 3개의 타입, 즉, (a) 요구형, (b) 임펄스, 및 (c) 벡터의 클라이언트 요청들 (675) 이 프레임워크 관리자 (440) 에 의해 핸들링되는지를 기술할 것이다. 위에서 언급한 요청들 (675) 의 명칭들이 시사하듯이, 클라이언트 요청들 (675) 은 일반적으로 위에서 생성되고 설명된 클라이언트 타입들에 대응한다.
블록 (1405) 에서, 프레임워크 관리자 (440) 는 위에서 언급한 3 개, 즉 (a) 요구형, (b) 임펄스, 및 (c) 벡터 중 하나와 같은, 특정한 클라이언트 요청 (675) 과 연관된 데이터를 수신할 수도 있다. 요구된 요청과 연관된 데이터는 일반적으로 그 요구된 클라이언트 (648) 로부터 특정한 리소스 (601) 로 전달되는 스칼라 값을 포함한다. 예를 들어, 요구된 요청은 특정수의 MIPs (millions of instructions per second) 를 포함할 수도 있다. 임펄스 요청은 시작 시간 또는 정지 시간의 임의의 지정 없이, 어떤 시간 기간 내에 일부 활동을 완료하라는 요청을 포함한다. 벡터 요청에 대한 데이터는 일반적으로 직렬로 또는 병렬로 완료되도록 요구되는 다수의 액션들의 어레이를 포함한다. 벡터 요청은 임의의 길이의 값들을 포함할 수도 있다. 벡터 요청은 일반적으로 사이즈 값 및 값들의 어레이를 갖는다. 노드 (601) 의 각각의 리소스는 벡터 요청을 지원하기 위해 포인터 필드를 갖도록 확장될 수도 있다. "C" 프로그래밍 언어에서, 포인터 필드는 당업자에 의해 이해되는 바와 같이 집합 기능 (union function) 에 의해 지원받는다.
다음으로, 블록 (1410) 에서, 프레임워크 관리자 (440) 는 그 요청을, 도 11 과 관련하여 위에서 설명한 방법에 의해 생성된 클라이언트 (648) 를 통해서 발행한다. 후속하여, 블록 (1415) 에서, 프레임워크 관리자 (440) 는 그 요청이 요구형 타입 또는 벡터 타입이면, 클라이언트를 통과중인 그 요청 데이터를 이중 버퍼링한다. 그 요청이 임펄스 타입이면, 블록 (1415) 은 프레임워크 관리자 (440) 에 의해 스킵된다.
요구된 요청들에 대해, 이 블록 (1415) 에서, 이전 요청으로부터의 값들은 프레임워크 관리자 (440) 가 요청된 값들의 현재 세트에서 이전 요청된 값들 사이에 어떤 차이가 있는지 여부를 결정할 수도 있도록, 메모리에 유지된다. 벡터 요청들에 대하여, 이전 요청들은 일반적으로 메모리에 유지되지 않지만, 노드 (601) 의 리소스는 특정한 구현에 대해 원하는 바에 따라 유지할 수도 있다. 따라서, 블록 (1415) 은 벡터 타입의 요청들에 대해 옵션적이다.
블록 (1420) 에서, 프레임워크 관리자 (440) 는 요청된 값들의 현재의 세트에서 요청된 값들의 이전 세트 사이의 델타 (delta) 또는 차이를 계산한다. 결정 블록 (1425) 에서, 프레임워크 관리자는 요청된 값들의 현재의 세트가 요청된 값들의 이전 세트에 동일한지 여부를 결정한다. 즉, 프레임워크 관리자 (440) 는 요청된 값들의 현재의 세트와 요청된 값들의 이전 세트 사이에 차이가 존재하는지 여부를 결정한다. 요청된 값들의 현재의 세트와 이전 세트 사이에 어떤 차이도 없다면, "예" 브랜치에 이어서 (블록 (1430) 내지 블록 (1470) 을 스킵하고고) 블록 (1475) 이 뒤따르며, 여기서 프로세스가 종료한다.
결정 블록 (1425) 에 대한 문의가 부정이면, 요청된 값들의 세트가 사전의-이전 요청된 값들의 세트에 대해 상이하다는 것을 의미하며, "아니오" 브랜치에 이어서 결정 블록 (1430) 이 뒤따른다.
결정 블록 (1430) 에서, 프레임워크 관리자 (440) 는 현재의 요청이 비동기적 요청인지를 결정한다. 결정 블록 (1430) 에 대한 문의가 부정이면, "아니오" 브랜치에 이어서 블록 (1440) 이 뒤따르며, 여기서, 클라이언트 요청 (675) 에 대응하는 리소스 (601) 가 프레임워크 관리자 (440) 에 의해 록킹된다. 결정 블록 (1430) 에 대한 문의가 긍정이면, 이는 현재의 요청이 비동기적 요청 타입임을 의미하며, 그 후에 "예" 브랜치에 이어서 블록 (1435) 이 뒤따르며, 여기서, 요청이 또 다른 스레드 상으로 푸시될 수도 있으며, 도 1 의 것과 유사한, 멀티코어 시스템이 프레임워크 관리자 (440) 에 의해 현재 관리된다면, 또 다른 코어에 의해 실행될 수도 있다. 블록 (1435) 은, PCD (100) 가 단일 코어 중앙 프로세싱 시스템이면, 이 단계가 옵션적일 수도 있다는 것을 나타내기 위해 파선들로 예시되어 있다.
후속하여, 블록 (1440) 에서, 요청 (675) 에 대응하는 리소스들 (601) 은 프레임워크 관리자 (440) 에 의해 록킹된다. 다음으로, 블록 (1445) 에서, 리소스 (601) 는 일반적으로 도 9 의 블록 (1130) 에서 수신된 리소스 어레이 데이터의 플러그-인 데이터에 대응하는 업데이트 기능을 실행한다. 업데이트 기능은 일반적으로 새로운 클라이언트 요청을 고려하여 새로운 리소스 상태를 담당하는 기능을 포함한다. 업데이트 기능은 클라이언트 요청에서 그의 이전 상태를 요청된 상태와 비교한다. 그 요청된 상태가 이전 상태보다 더 크면, 업데이트 기능은 클라이언트 요청을 수행할 것이다. 그러나, 그 요청된 상태가 현재의 상태와 동일하거나 더 작고 리소스가 그 요청된 상태에서 동작 중이면, 구 (old) 상태가 요청된 상태를 달성하거나 또는 만족하므로 효율을 증가시키기 위해 클라이언트 요청은 수행되지 않을 것이다. 업데이트 기능은 클라이언트로부터 새로운 요청을 취하여 모든 다른 활성 요청들과 종합하여, 그 리소스에 대한 새로운 상태를 결정한다.
일 예로서, 다수의 클라이언트들이 버스 클록 주파수를 요청하고 있을 수도 있다. 버스 클록에 대한 업데이트 기능은 일반적으로 모든 클라이언트 요청들의 최대치를 취하고 그것을 버스 클록에 대한 새로운 원하는 상태로서 이용할 것이다. 다수의 리소스들에 의해 이용될 일부 업데이트 기능들이 있지만, 모든 리소스들이 동일한 업데이트 기능을 이용할 것이라는 것은 사실이 아니다. 일부 공통 업데이트 기능들은 클라이언트 요청들의 최대치를 취하고, 클라이언트 요청들의 최소치를 취하고, 클라이언트 요청을 합산할 것이다. 또는, 리소스들은 그들의 리소스가 요청들을 어떤 고유한 방법으로 집합할 필요가 있다면, 그들 자신의 맞춤 업데이트 기능을 정의할 수도 있다.
다음으로, 블록 (1450) 에서, 프레임워크 관리자 (440) 는 리소스가 노드 (601) 의 리소스에 특정한 드라이버 기능을 실행할 수 있도록, 데이터를 클라이언트 (648) 에 대응하는 리소스로 전달한다. 드라이버 기능은 업데이트 기능에 의해 계산된 것과 같이 리소스 상태를 적용한다. 이것은 하드웨어 설정들을 업데이트하고, 의존적인 리소스들에 대한 요청들을 발행하고, 레거시 기능들 또는 상술한 것의 일부 조합을 호출하는 것을 수반할 수도 있다.
이전 실시예에서는, 업데이트 기능이 요청된 버스 클록 주파수를 계산하였다. 드라이버 기능은 그 요청된 주파수를 수신할 수도 있으며, 그 주파수에서 실행하기 위해 클록 주파수 제어 HW 를 업데이트할 수도 있다. 종종 업데이트 기능이 계산되었던 정확한 요청된 상태를 드라이버 기능이 만족시키는 것이 불가능하다는 점에 유의한다. 이 경우, 드라이버 기능은 그 요청을 최선으로 만족시키는 주파수를 선택할 수도 있다. 예를 들어, 버스 클록 HW 은 오직 128 MHz 및 160 MHz 에서 실행할 수도 있지만, 그 요청된 상태는 150 MHz 일수도 있다. 이 경우, 드라이버 기능은 그것이 그 요청된 상태를 초과하므로, 160 MHz 에서 실행해야 한다.
다음으로, 블록 (1455) 에서, 프레임워크 관리자 (440) 는 블록 (1450) 에서 드라이버 기능을 실행했던 리소스로부터 상태 제어를 수신한다. 후속하여, 블록 (1460) 에서, 리소스에 대해 정의한 경우, 이벤트들 (690) 은 데이터가 이벤트 (690) 에 대응하는 클라이언트 (648) 로 다시 전달되도록, 트리거될 수도 있다. 이벤트들은 또 다른 스레드에서 프로세싱될 수도 있다. 이것은 리소스들이 록킹는데 소요되는 시간의 양을 최소화할 수도 있으며, 도 1 에 예시된 바와 같은 멀티코어 시스템에서 병렬 동작을 허용한다. 하나 이상의 이벤트들 (690) 은 요청이 이 방법 (1400) 에서 설명되는 바와 같이 리소스에 대해 정의될 수도 있는 방식과 유사한 방법으로 리소스에 대해 정의될 수도 있다. 즉, 이벤트 생성 프로세스는 클라이언트 생성 프로세스와 대개 병렬일 수도 있다. 이벤트들과 상이한 한가지 사항은 어떤 임계치들이 교차될 때에만 오직 트리거되게 하는 이벤트들을 정의하는 것이 가능하다는 것이다.
오직 임계치들에 기초하여 트리거되게 하는 이벤트들의 이 정의는, 시스템 오버로딩 상태를 나타내는, 리소스가 초과 신청되고 있을 때 (리소스가 지원할 수 있는 사용자들보다 더 많은 동시 사용자들을 갖는다), 또는 리소스가 낮아지거나/오프될 때의 통지를 가능하게 하며, 이것은 다른 것들이 정지될 수 있게 하여, 시스템이초과 청되어질 때 기타 등등에 의해 디스에이블되었던 기능을 복구할 수도 있다. 이벤트 등록이 임계치들에 의해 실행될 수도 있기 때문에, 실제로 필요한 어떤 것이 있을 경우에만 발생하도록 시스템이 이벤트 통지에 대해 실행해야 할 작업의 양을 감소시킨다. 또한, 모든 상태 변화에 대한 이벤트를 등록하는 것도 가능하다.
다음으로, 옵션적인 블록 (1465) 에서, 프로세싱되고 있는 요청이 벡터 요청이면, 이 옵션적인 블록 (1465) 이 일반적으로 수행된다. 옵션적인 블록 (1465) 은 일반적으로 사용자가 벡터에 전달한 동일한 데이터 상에 벡터 포인터가 여전히 위치되어 있는지 여부를 평가하는 체크 또는 결정을 포함한다. 이 옵션적인 블록 (1465) 에 대한 문의가 긍정이면, 포인터가 사용자에 의해 벡터로 전달되었던 동일한 데이터를 여전히 가리키고 있다는 것을 의미하며, 구 데이터에 대한 참조들이 유지되지 않도록, 포인터가 비워진다. 이 옵션적인 블록 (1465) 은 임펄스 요청 및 요구된 요청에 비해, 벡터 요청이 프로세싱되고 있을 때, 위에서 설명한 이중 버퍼링 블록 (1415) 을 고려하기 위해 일반적으로 수행된다.
후속하여, 블록 (1470) 에서, 프레임워크 (440) 는 다른 클라이언트 요청들 (648) 이 현재이지만 지금 해제된, 특정한 노드 (601) 의 요청된 리소스에 의해 핸들링될 수 있도록, 그 요청된 리소스를 언록킹한다. 프로세스는 그 후 다음 클라이언트 요청을 수신하는 제 1 블록 (1405) 으로 리턴한다.
전술된 방법들 및 데이터 구조들은 본직적으로 단일-프로세서 PCD (100) 에 적용가능한 것과 같이 멀티-프로세서 PCD (100) 에 적용가능하다. 그러나, 원격 프레임워크 (300; 도 3) 는 멀티-프로세서 실시형태에서 동작을 개선할 수도 있는 추가의 특징들을 제공할 수도 있다. 예를 들어, 원격 프레임워크 (300) 는 애플리케이션 프로그래머 또는 유사한 사람에게 투명한 프로세서간 통신의 세부사항들을 유리하게 렌더링할 수도 있다. 따라서, 애플리케이션 프로그램은, 예를 들어 타겟 리소스에 대한 요청을, 클라이언트 정의에서 그 리소스를 제어하는 프로세서 도메인의 임의의 식별을 포함해야할 필요 없이 발행하는, 클라이언트를 정의할 수도 있다. 오히려, 원격 프레임워크 (300) 는 어떤 프로세서가 클라이언트를 제어하는지와 어떤 프로세서가 타겟 리소스를 제어하는지에 관계없이, 요청이 타겟 리소스에 도달할 것을 보장한다. 추가로, 원격 프레임워크 (300) 는, 예컨대 애플리케이션 프로그램이 프로세서들 간의 통신 경로들 (예컨대, 버스들) 의 프로토콜 또는 다른 양태들과 관련된 임의의 명령들을 포함해야할 필요가 없도록, 프로세서간 통신을 관리한다. 추가로, 상이한 프로세서간 통신 경로들이 상이한 프로토콜들을 사용할 수도 있기 때문에, 원격 프레임워크 (300) 는 리소스 정의가 리소스의 다른 양태들과 함께 프로토콜을 규정하게 한다. 분산 리소스 관리와 관련된 이러한 특징 및 다른 특징은 도 13 내지 도 17 과 관련하여 이하 설명된다.
도 13 은 제 1 프로세서 (비도시) 에 의해 제어되는 제 1 리소스 (1302) 가 제 2 프로세서 (비도시) 에 의해 제어되는 제 2 리소스 (1304) 에 대응하는 분산 또는 원격 리소스로서 기능하는, 일 실시예 또는 경우를 예시한다. 용어 "분산 리소스" 또는 "원격 리소스" 는 다른 프로세서 상의 "네이티브" 리소스에 대응하는 일 프로세서 상의 리소스를 지칭하도록 본 개시물에서 사용된다. 상기 실시예에서 제 2 리소스 (1304) 는 제 2 프로세서에 대한 네이티브 리소스 역할을 한다. 분산 리소스는 대응하는 네이티브 리소스에 액세스하기 위한 수단으로서 사용된다. 이 실시예에서, 용어 "리소스" 는, 리소스가 노드에 포함될 수도 있는 것이 이해되어야만 하기 때문에, 용어 "노드" 와 상호교환가능하게 사용될 수도 있다.
파선 (1301) 은 (그 선 (1301) 의 좌측에서) 제 1 프로세서에 의해 제어된 리소스들과 (그 선 (1301) 의 우측에서) 제 2 프로세서에 의해 제어된 리소스들 간의 분할을 예시한다. 제 1 리소스 (1302) 는 제 1 프로세서에 의해 제어되는 2 이상의 리소스들 중 하나이다. 하나의 그러한 리소스는 제 1 리소스 (1302) 가 의존하는 프로토콜 리소스 (1306) 일 수도 있다. 유사하게, 제 2 리소스 (1304) 는 제 2 프로세서에 의해 제어되는 2 이상의 리소스들 중 하나이다. 일부 실시형태들에서, 오직 분산 리소스만이 프로토콜 리소스에 의존하며, 네이티브 리소스는 프로토콜 리소스에 의존하지 않는다. 따라서, 그러한 실시형태들에서 오직 제 1 (분산) 리소스 (1302) 만이 프로토콜 리소스 (1306) 에 의존한다. 그러나, 다른 실시형태들에서 임의의 리소스는 프로토콜 리소스에 의존할 수도 있다. 따라서, 대안적인 실시형태에서 제 2 리소스 (1304) 는 또한 프로토콜 리소스 (비도시) 에 의존할 수 있다. 제 1 및 제 2 리소스들 (1302 및 1306) 은 또한 일반적으로 리소스들 또는 노드들과 관련하여 전술된 것과 동일한 방식으로 추가의 리소스들에 의존하지만, 그러한 추가의 리소스들은 명확함을 목적으로 도 13 에 도시되지 않는다. 제 1 프로세서에 의해 제어되는 리소스들은 제 1 리소스 그래프 (즉, 방향성 비순환 그래프) 에 의해 정의되며, 제 2 프로세서에 의해 제어되는 리소스들은 제 1 리소스 그래프와 어떤 리소스들도 공유하지 않는 제 2 의 리소스 그래프에 의해 정의되는 것에 유의한다.
제 1 및 제 2 리소스들 (1302 및 1304) 은, 그들 각각의 프로세서들의 제어하에, 통신 경로 (1302) 를 통해 정보를 통신할 수 있다. 통신 경로 (1303) 는 제 1 및 제 2 프로세서들 간의 물리적 매체 및 그 매체를 통해 통신하는데 사용되는 전송 프로토콜들의 하나 이상의 층들의 조합을 나타낸다. 따라서, 제 1 리소스 (1302) 와 제 2 리소스 (1304) 간의 임의의 통신은 그 프로토콜들을 따라야만 한다. 프로토콜 리소스 (1306) 는 프로토콜을 정의하거나, 라이브러리 (비도시) 에서 프로토콜 정의를 가리킬 수도 있다. 원격 프레임워크 (300) 및 (메인) 프레임워크 (440) 는 리소스들 및 그들 간의 통신들을 관리하기 위해 서로 결합하여 동작한다. 이하 설명되는 것과 같이, 클라이언트 (1312) 는 제 1 프로세서의 제어하에, 제 1 리소스 (1302) 에 대한 하나 이상의 리소스 요청들을 발행할 수도 있다. 제 1 리소스 (1302) 는 리소스 요청을 서비스하기 위해 대응하는 제 2 리소스 (1304) 의 기능성을 사용한다.
도 14 는 도 13 의 제 1 리소스 (1302) 와 같은 분산 리소스를 생성하거나 인스턴스화하는 방법 (1400) 을 예시하는 플로우차트이다. 도 14 의 플로우차트는 도 7 내지 도 10 에 예시된 방법과 같은, 리소스들을 인스턴스화하는 방법들과 관련하여 전술된 특징에 부가하거나 그 특징들을 증가시키는 특징들을 예시하도록 의도된다. 따라서, 달리 표시되지 않는다면, 도 7 내지 도 10 의 블록들 중 임의의 블록 또는 모든 블록들은 포함될 수도 있지만, 명확성의 목적들을 위해 도 14 에 포함되지 않는다.
블록 (1402) 에 의해 표시되는 것과 같이, 프레임워크 관리자들 (300 및 440) 은 제 1 리소스 (1302) 를 포함하는 것과 같은, 노드를 정의하는 노드 구조 데이터를 수신한다. 예시적인 실시형태에서, 의존성들은 블록 (1406) 에 의해 표시되는 것과 같이 프로토콜 리소스들이 임의의 시간에 인스턴스화될 수도 있다는 점을 제외하면, 도 7 내지 도 10 과 관련하여 전술된 것과 본질적으로 동일한 방식으로 핸들링된다. 프로토콜 리소스에 의존하는 리소스는 그 프로토콜 리소스가 인스턴스화될 때가지 대기해야할 필요가 없다. 도 7 내지 도 10 과 관련하여 전술된 방식의 의존성들의 인스턴스화는 일반적으로 블록 (1408) 에 의해 예시된다.
인스턴스화는 일반적으로 도 7 내지 도 10 과 관련하여 전술된 방법들을 뒤따르지만, 분산 리소스는 대응하는 네이티브 리소스가 인스턴스화될 때까지 인스턴스화될 수 없음에 유의하여야 한다. 따라서, 네이티브 리소스의 인스턴스화는 의존 리소스들의 인스턴스화가 그들에 의존하는 리소스의 인스턴스화를 지연시킬 수 있는 것과 동일한 방식으로 분산 리소스의 인스턴스화를 지연시킬 수도 있다. 또한, 통신 경로 (1310) 를 통해 제 1 및 제 2 프로세서들과 프레임워크 관리자들 (300 및 440) 간에 통신되는 네이티브 리소스의 인스턴스화의 상태에 관련된 메세지들은 일반적으로 특정 프로토콜을 따르는 것에 유의하라. 예를 들어, 제 1 프로세서 상의 프로토콜 리소스 (1306) 가 인스턴스화된 이후, 원격 프레임워크 관리자 (300) 에 따라 동작하는 제 1 프로세스는 인코딩되거나 그렇지 않으면 프로토콜을 따르는 통지에 대한 요청을 제 2 프로세서에 전송할 수도 있다. 제 2 리소스 (1304) 가 인스턴스화된 경우, 원격 프레임워크 관리자 (300) 에 따라 동작하는 제 2 프로세서는 제 2 리소스 (1304) 가 인스턴스화된 것을 나타내는 응답을 제 1 프로세서에 전송함으로서 통지에 대한 요청에 응답할 수도 있다. 원격 프레임워크 관리자 (300) 는 소프트웨어 아키텍처를 인스턴스화하는 프로세서의 일부로서 그러한 통신들 및 다른 통신들을 관리할 수도 있다.
제 1 프로세서 상의 프로토콜 리소스 (1306) 는 다른 기능들 중에서, 도 13 에 도시된 클라이언트 (1312) 와 같은 클라이언트를 생성하기 위한 기능을 포함하고, 실행 스레드에 의해 사용될 수도 있는 클라이언트를 핸들링하도록 리턴할 수도 있다. 실행 스레드 (예컨대, 애플리케이션 프로그램 또는 다른 소프트웨어 엘리먼트의 실행의 일부) 는 그러한 클라이언트 (1312) 를 생성하는 기능을 호출할 수도 있다. 스레드는 리소스 요청들을 발행하기 위해 클라이언트 (1312) 를 사용할 수도 있고, 그렇지 않으면 일반적으로 클라이언트들과 관련하여 전술된 것과 동일한 방식으로 클라이언트 (1312) 를 사용할 수도 있다. 리소스 요청은 프로토콜에 특정되며, 스레드가 그 프로토콜에 관련된 임의의 정보를 제공해야할 필요없이 스레드가 제 2 리소스 (1304) 에 액세스하는 것을 허용한다. 스레드 및 그 클라이언트들의 관점에서, 프로토콜은 관련이 없거나 투명할 수도 있다.
블록 (1410) 에 의해 표시된 것과 같이, 프레임워크들 (300 및 440) 은 집합 방법이 수신된 노드 구조 데이터에 명시되는지 결정한다. 집합 방법이 명시되는 것으로 결정된다면, 집합 방법은 블록 (1412) 에 의해 표시된 것과 같이 분산 및 네이티브 리소스들 (노드들) 에서 세팅된다. 2 가지 집합 타입들: 로컬 및 프록시가 존재한다. 리소스를 정의할 시, 2 개의 집합 타입들 중 하나가 선택될 수도 있다. 따라서, 리소스 (노드) 를 인스턴스화할 시, 리소스는 로컬 집합 및 원격 집합을 수행하도록 세팅된다.
리소스는 "동시에" 수신할 수도 있는 다수의 리소스 요청들에 알고리즘을 적용함으로써 로컬 집합을 수행한다. 이러한 문맥에서, 2 개 (또는 그 이상) 의 요청들은 그들 모두가 활성을 유지하는 시간 동안 "동시적" 이다. 예를 들어, 제 1 프로세서는 그 속도를 50 MIPS 로 세팅하는 리소스 요청을 발생할 수도 있고, 제 1 프로세서의 요청이 완료되거나 그렇지 않으면 종료되기 전에 제 2 프로세서는 그 속도를 100 MIPS 로 세팅하는 리소스 요청을 발행할 수도 있다. 집합은 다수의 동시의 리소스 요청들 각각의 인수를 부가하는 것과 같은 방법에 따라, 모든 다수의 리소스 요청들 중으로부터 최대 인수를 결정함으로써, 모든 다수의 리소스 요청들 중으로부터 최소 인수를 결정함으로써, 또는 임의의 다른 적합한 방법에 의해 수행될 수도 있다. 집합 방법은 리소스 (노드) 를 정의하는 노드 구조 데이터에서 집합 타입과 함께 명시되거나 정의될 수도 있다.
노드 구조 데이터는 노드가 프록시 노드 또는 비-프록시 노드로서 인스턴스화될 것을 나타낼 수도 있다. 이러한 특징이 사용될 수 있는 방식은 도 16 및 도 17 과 관련하여 이하 설명된다. 블록 (1414) 에 의해 표시되는 것과 같이, 노드 타입은 표시된 타입으로 세팅된다. 비-프록시 모드의 경우, 클라이언트 요청들은 노드 구조에 의해 결정된 방식으로 국부적으로 집합되며, 국부적으로 집합된 요청을 네이티브 리소스에 전송하는 드라이버 기능이 사용된다. 쿼리들 및 이벤트들은 분산 리소스에 의해 핸들링된다. 프록시 노드의 경우, 클라이언트 요청들은 집합되는 것이 아니라, 대신에 네이티브 리소스들에 개별적으로 전송된다. 부가적으로, 모든 쿼리들 및 이벤트들은 네이티브 리소스로 포워딩된다.
블록 (1416) 에 의해 표시된 것과 같이, 인스턴스화 프로세스에서 임의의 나머지 단계들이 발생한다. 분산 노드를 인스턴스화하는 그러한 양태들은 도 7 내지 도 10 과 관련하여 전술된 것과 본질적으로 동일할 수도 있다. 블록 (1418) 에 의해 표시되는 것과 같이, 추가의 노드들이 정의된다면, 방법은 그들의 노드들에 대하여 반복되거나 진행된다.
도 15 는 클라이언트 요청을 서비스하는 방법 (1500) 을 예시하는 플로우차트이다. 도 15 의 플로우차트는 도 12 에 예시된 방법과 관련하여 전술된 특징들에 부가되거나 그 특징들을 증가시키는 특징들을 예시하도록 의도된다. 따라서, 달리 표시되지 않는다면, 도 12 의 블록들 중 임의의 블록 또는 모든 블록들은 포함될 수도 있지만, 명확성의 목적들을 위해 도 15 에 포함되지 않는다.
블록 (1502) 에 의해 표시되는 것과 같이, 도 13 의 제 1 노드 (1302) 와 같은 분산 리소스는 클라이언트 요청을 수신한다. 블록 (1504) 에 의해 표시되는 것과 같이, 요청된 리소스와 연관된 집합 타입이 로컬인지 또는 원격인지 여부가 결정된다. 집합 타입이 로컬이라면, 요청된 리소스는 요청 인수를 블록 (1506) 에 의해 표시된 것과 같이 동일한 윈도우 내에서 발생하는 다른 인수들과 집합시킨다. 전술된 것과 같이, 집합은 동시의 리소스 요?들을 핸들리하는 것과 관련된다. 요청된 리소스와 연관된 집합 타입이 원격이라면, 이는 다른 리소스들과의 요청을 집합하기 위해 도 13 에서 제 2 리소스 (1304) 와 같은 대응하는 네이티브 리소스에 일임될 것이다.
로컬인지 또는 원격인지 간에, 집합은 클라이언트 요청의 3 개의 순차적인 상태들을 보여준다: (1) 발행된 요청, (2) 진행중인 요청 및 (3) 적용된 요청. 클라이언트 요청들이 동시에 발행되는, 즉 2 개의 클라이언트 요청들이 각각 실질적으로 동시에 또는 서로의 앞서 참조된 윈도우 내에 발행된 요청 상태를 시작하는 인스턴스에서, 최초 발생한 클라이언트 요청은 요청된 리소스가 록킹되게 하고, 2 번째 발생한 클라이언트 요청은 최초 발생한 클라이언트 요청 이후에 핸들링된다. 클라이언트 요청은 진행중 요청 상태 동안 핸들링되거나 서비스된다. 클라이언트가 완료된 후에, 클라이언트 요청에는 적용된 요청 상태가 할당된다. 집합은 다수의 동시의 클라이언트 요청들이 적용된 요청 상태에 도달한 인스턴스에서 활동하기 시작한다. 예를 들어, 리소스가 앞서 참조된 최대 집합 방법을 사용하는 것으로 정의되고, 클라이언트 "A" 가 50 MIPS 를 요청하는 반면 아마도 수 마이크로초 이후에 클라이언트 "B" 가 100 MIPS 를 요청한다면, 이들 초기 요청들은 직렬화될 것이다. 따라서, 제 1 클라이언트 요청이 프로세싱될 경우, 리소스는 제 1 클라이언트 요청의 인수 또는 50 MIPS 로 세팅될 것이다. 그 후에, 제 2 클라이언트 요청이 프로세싱될 경우, 리소스는 최대 집합 방법에 따라 100 으로 세팅될 것이며, 이는 100 이 50 과 100 중 최대치이기 때문이다. 그 후에, 이들 초기 클라이언트 요청들 양자가 적용된 요청 상태에 있을 경우, 클라이언트 "B" 는 25 MIPS 동안 다른 클라이언트 요청을 발행할 수도 있다. 요청된 리소스는, 최대 집합 방법에 따라, 50 으로 세팅될 것이며, 이는 50 이 50 과 25 의 최대치이기 때문이다.
블록 (1508) 에 의해 표시되는 것과 같이, 요청된 리소스가 도 13 의 프로토콜 리소스 (1306) 와 같은 프로토콜 리소스에 의존하는지 여부가 결정된다. 요청된 리소스가 프로토콜 리소스에 의존한다면, 그 후에 프로토콜 리소스가 호출되고, 리소스 요청을 개별적으로 블록 (1510 및 1512) 에 의해 표시되는 것과 같이 프로토콜 리소스가 정의하는 프로토콜에 순응시키는데 사용된다. 블록 (1514) 에 의해 표시되는 것과 같이, 프로토콜에 순응하여, 도 13 의 제 2 리소스 (1304) 와 같은 네이티브 리소스로 집합 결과 (블록 (1506) 의 결과) 를 반영하는 리소스 요청이 전송되거나, 원격 리소스가 집합을 수행하기 위한 것일 경우, 리소스 요청이 포워딩된다. 분산 리소스의 드라이버 기능 (비도시) 은 프로토콜을 호출한다.
도 15 에 도시되지는 않았지만, 분산 리소스들과 연관된 이벤트들은 도 12 와 관련하여 전술된 것과 본질적으로 동일한 방식으로 핸들링될 수도 있다. 임계치를 교차하는 값에 대하여 모니터하는 타입의 이벤트들은 이하 설명되는 것과 같이 프록시 리소스와 결합하여 본질적으로 유용할 수도 있다.
도 16 은 비-프록시 타입의 분산 리소스에 대한 상태 쿼리를 서비스하는 방법 (1600) 을 예시하는 플로우차트이다. 상태 쿼리들은 도 5 및 도 6 과 관련하여 전술된 것과 같이 프레임워크 (440) 에 의해 관리된다. 도 16 및 도 17 의 플로우차트들은 도 5 및 도 6 과 관련하여 전술된 특징들에 부가하거나 그 특징들을 증가시키는 특징들을 예시하도록 의도된다. 따라서, 달리 표시되지 않는다면, 도 5 및 도 6 관련하여 전술된 임의의 특징들 또는 모든 특징들은 포함될 수도 있지만, 명확성의 목적들을 위해 도 16 및 도 17 에 도시되지 않는다.
블록 (1602) 에 의해 표시되는 것과 같이, 도 13 의 제 1 노드 (1302) 와 같은 분산 리소스는 상태 쿼리를 수신한다. 이러한 실시예에서, 제 1 노드 (1302) 는 비-프록시 노드 또는 리소스를 나타낸다. 블록 (1604) 에 의해 표시된 것과 같이, 상태 쿼리는 도 13 의 제 2 리소스 (1304) 와 같은 대응하는 네이티브 리소스로 포워딩된다. 블록 (1606) 에 의해 표시된 것과 같이, 네이티브 리소스의 상태는 상태 쿼리에 응답하여 분산 리소스로 다시 전송된다. 블록 (1608) 에 의해 표시된 것과 같이, 그 후에, 분산 리소스는 네이티브 리소스의 상태를 나타내는 상태 표시를 쿼리 요청자 (클라이언트) 에 제공할 수도 있다.
도 17a 는 프록시 타입의 분산 리소스에 대한 상태 쿼리를 서비스하는 방법 (1700) 의 제 1 부분을 예시하는 플로우차트이다. 블록 (1702) 에 의해 표시되는 것과 같이, 도 13 의 제 1 노드 (1302) 와 같은 분산 리소스는 상태 쿼리를 수신한다. 이러한 실시예에서, 제 1 노드 (1302) 는 프록시 노드 또는 리소스를 나타낸다. 각각 블록들 (1704 및 1706) 에 의해 표시된 것과 같이, 분산 리소스가 네이티브 리소스의 상태의 표시를 수신할 때마다, 분산 리소스는 네이티브 리소스의 상태를 반영하도록 그 상태를 업데이트한다. 블록 (1608) 에 의해 표시된 것과 같이, 분산 리소스는 그 자신의 상태의 표시를 쿼리 요청자 (클라이언트) 에 제공한다. 따라서, 프록시 분산 리소스의 경우, 그 상태는 오직 대응하는 네이티브 리소스로부터 상태의 변경에 대한 통지를 수신할 경우에만 변화한다.
블록에 의해 표시된 것과 같이, 상태 쿼리는 도 13 의 제 2 리소스 (1304) 와 같은 대응하는 네이티브 리소스로 포워딩된다. 블록 (1606) 에 의해 표시된 것과 같이, 네이티브 리소스의 상태는 상태 쿼리에 응답하여 분산 리소스로 다시 전송된다.
도 17b 는 프록시 타입의 분산 리소스에 대한 상태 쿼리를 서비스하는 방법 (1700) 의 제 2 부분을 예시하는 플로우차트이다. 이러한 제 2 부분은 네이티브 리소스의 관점을 반영하며, 도 17a 에 도시된 제 1 부분과 비동기적으로 및 병렬로 동작한다. 블록 (1710) 에 의해 표시된 것과 같이, 도 13 의 제 2 노드 (1304) 와 같은 네이티브 리소스의 상태가 모니터링된다. 각각 블록들 (1712 및 1714) 에 의해 표시된 것과 같이, 네이티브 리소스의 상태에 있어서의 변화가 검출된다면, 네이티브 리소스의 상태의 표시는 대응하는 분산 리소스로 전송된다.
적절한 경우, 프록시 분산 리소스의 사용은 프로세서간 트래픽을 최소화하는 바람직한 목표를 촉진할 수도 있으며, 이는 상태 정보가 오직 네이티브 리소스의 상태가 변화할 경우에 네이티브 리소스의 프로세서로부터 분산 리소스의 프로세서로 전송되기 때문이다. 대조적으로, 비-프록시 리소스의 경우에, 분산 리소스가 상태 쿼리를 수신할 때마다 상태 쿼리가 전송되고 상태 정보가 리턴된다. 프록시 리소스들은 예를 들면, 제 1 프로세서의 제어하에 수행될 작업과 가장 관련된, 대응하는 네이티브 리소스보다는 분산 리소스의 상태에 있는 경우들에서 사용될 수도 있다.
도 5 및 도 6 과 관련하여 전술된 것과 같이, 이벤트들 및 쿼리들은 소프트웨어 아키텍처의 관련된 양태들이다. 임계치를 지나가는 값에 대하여 모니터링하는 타입의 이벤트들은 프록시 리소스와 결합하여 특히 유용할 수도 있으며, 이는 프로세서간 메세지들이 네이티브 리소스의 상태가 변화할 때마다 보다는 네이티브 리소스의 상태가 임계치를 가로지를 경우에만 전송되기 때문이다.
앞의 개시물의 관점에서, 당업자는, 예를 들어, 본 명세서에 있어서의 플로우 차트들 및 연관된 설명에 기초하여 어려움없이, 분산 리소스 관리 시스템 및 방법을 구현하기 위해 컴퓨터 코드를 기입하거나 적절한 하드웨어 및/또는 다른 로직 또는 회로들을 식별할 수 있다. 따라서, 프로그램 코드 명령들 또는 상세한 하드웨어 디바이스들의 특정 세트의 개시는 분산 리소스 관리 시스템 및 방법을 형성하고 이용하는 방식의 적절한 이해에 필수적인 것으로 고려되지 않는다. 청구된 컴퓨터 구현 프로세스들의 본 발명의 기능성은, 다양한 프로세스 플로우들을 예시할 수도 있는 도면들과 함께 상기 설명에서 더 상세히 설명된다. 또한, 프로세서들 (110, 126, 202, 206 등) 은, 메모리 (112) 및 그에 저장된 명령들과 결합하여, 본 명세서에서 설명되는 방법 단계들 중 하나 이상을 수행하는 수단으로서 기능할 수도 있다.
하나 이상의 예시적인 양태들에서, 상술된 기능들은 하드웨어, 소프트웨어, 펌웨어 또는 이들의 임의의 조합으로 구현될 수도 있다. 소프트웨어에서 구현된다면, 그 기능들은 하나 이상의 명령들 또는 코드로서 컴퓨터 판독가능 매체 상으로 저장 또는 전송될 수도 있다. 컴퓨터 판독가능 매체들은 한 장소에서 다른 장소로 컴퓨터 프로그램의 전송을 가능하게 하는 임의의 매체를 포함하여 컴퓨터 저장 매체들 및 통신 매체들 양자를 포함한다. 저장 매체는 컴퓨터에 의해 액세스될 수 있는 임의의 이용 가능한 매체일 수도 있다. 비제한적인 예로서, 이러한 컴퓨터 판독가능 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광학 디스크 스토리지, 자기 디스크 스토리지 또는 다른 광학 또는 자기 스토리지 디바이스들, 또는 요구되는 프로그램 코드를 명령들 또는 데이터 구조들의 형태로 이송 또는 저장하기 위해 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 본 명세서에서 사용되는 바와 같은 용어 "디스크 (disk)" 및 "디스크 (disc)" 는 컴팩트 디스크 ("CD"), 레이저 디스크, 광학 디스크, 디지털 다기능 디스크 ("DVD"), 플로피 디스크 및 블루레이 디스크를 포함하지만, 이에 제한되지 않는다. 위의 조합들도 컴퓨터 판독가능 매체들의 범위 내에 포함되어야 한다.
선택된 양태들이 예시되고 상세히 설명되었지만, 하기의 특허청구범위에 의해 정의되는 것과 같이 본 발명의 취지와 범위로부터 벗어나지 않으면서 여러 대체예들 및 수정예들이 이루어질 수도 있음을 이해해야만 할 것이다.

Claims (28)

  1. 제 1 프로세서에 의해 제어되는 제 1 복수의 리소스들 및 제 2 프로세서에 의해 제어되는 제 2 복수의 리소스들을 갖는 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 방법으로서,
    상기 제 1 프로세서에 의해 제어되는 제 1 노드를 인스턴스화하는 단계로서, 상기 제 1 노드는 상기 제 2 프로세서에 의해 제어되는 제 2 노드에 대응하고, 상기 제 1 복수의 리소스들은 제 1 방향성 비순환 그래프 (directed acyclic graph) 에 의해 정의되고, 상기 제 2 복수의 리소스들은 상기 제 1 방향성 비순환 그래프와 어떤 리소스들도 공유하지 않는 제 2 방향성 비순환 그래프에 의해 정의되며, 상기 제 1 방향성 비순환 그래프의 각 노드는 상기 제 1 프로세서에 의해 제어되는 하나 이상의 리소스들의 기능성의 캡슐화를 나타내고, 상기 제 1 방향성 비순환 그래프의 각 에지는 클라이언트 요청을 나타내고, 상기 제 1 방향성 비순환 그래프의 인접 노드들은 리소스 의존성들을 나타내며, 상기 제 2 방향성 비순환 그래프의 각 노드는 상기 제 2 프로세서에 의해 제어되는 하나 이상의 리소스들의 기능성의 캡슐화를 나타내고, 상기 제 2 방향성 비순환 그래프의 각 에지는 클라이언트 요청을 나타내고, 상기 제 2 방향성 비순환 그래프의 인접 노드들은 리소스 의존성들을 나타내는, 상기 제 1 프로세서에 의해 제어되는 제 1 노드를 인스턴스화하는 단계;
    상기 제 1 프로세서의 제어하에, 클라이언트로부터 클라이언트 요청을 상기 제 1 노드에서 수신하는 단계; 및
    상기 제 1 노드에서의 클라이언트 요청에 응답하여 상기 제 2 노드에서 클라이언트 요청을 발행하는 단계를 포함하는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 방법.
  2. 제 1 항에 있어서,
    상기 제 1 노드는 프로토콜 리소스에 의존하고, 상기 제 1 노드는 상기 프로토콜 리소스에 의해 정의된 전송 프로토콜을 호출하는 드라이버를 포함하도록 인스턴스화되며, 상기 드라이버는 상기 제 2 노드에서의 클라이언트 요청을 상기 전송 프로토콜에 순응시키는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 방법.
  3. 제 2 항에 있어서,
    상기 제 1 노드는 상기 프로토콜 리소스가 인스턴스화되고 상기 제 2 노드가 인스턴스화될 때까지 인스턴스화되지 않는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 방법.
  4. 제 1 항에 있어서,
    상기 제 1 노드에서 복수의 클라이언트 요청들을 수신하는 단계; 및
    수신된 상기 복수의 클라이언트 요청들을 상기 제 1 노드가 집합하여 집합 결과를 제공하는 단계를 더 포함하며,
    상기 제 2 노드에서 클라이언트 요청을 발행하는 단계는 상기 집합 결과에 대한 클라이언트 요청을 발행하는 단계를 포함하는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 방법.
  5. 제 1 항에 있어서,
    상기 제 1 노드에서 복수의 클라이언트 요청들을 수신하는 단계로서, 상기 제 2 노드에서 클라이언트 요청을 발행하는 단계는 상기 제 1 노드에서 발행된 상기 복수의 클라이언트 요청들에 대응하는 복수의 클라이언트 요청을 상기 제 2 노드에서 발행하는 단계를 포함하는, 상기 제 1 노드에서 상기 복수의 클라이언트 요청들을 수신하는 단계; 및
    상기 제 2 노드에서 발행된 상기 복수의 클라이언트 요청들을 상기 제 2 노드가 집합하여 집합 결과를 제공하는 단계를 더 포함하는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 방법.
  6. 제 1 항에 있어서,
    상기 제 1 프로세서의 제어하에 클라이언트로부터 제 1 상태 쿼리를 상기 제 1 노드에서 수신하는 단계;
    상기 제 2 노드의 상태의 표시를 획득하기 위해, 상기 제 2 노드에서 제 2 상태 쿼리를 발행하는 단계; 및
    상기 제 1 상태 쿼리에 응답하여 상기 제 2 노드의 상태의 표시를 상기 제 1 노드가 제공하는 단계를 더 포함하는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 방법.
  7. 제 1 항에 있어서,
    상기 제 1 프로세서의 제어하에 클라이언트로부터 제 1 상태 쿼리를 상기 제 1 노드에서 수신하는 단계;
    상기 제 1 상태 쿼리에 응답하여 상기 제 1 노드의 상태의 표시를 상기 제 1 노드가 제공하는 단계;
    상기 제 2 노드의 상태에서의 변화를 검출하는 단계; 및
    상기 제 2 노드의 상태에서의 변화의 검출에 응답하여 상기 제 2 노드의 상태의 표시를 상기 제 1 노드에 제공하는 단계를 더 포함하는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 방법.
  8. 제 1 프로세서에 의해 제어되는 제 1 복수의 리소스들 및 제 2 프로세서에 의해 제어되는 제 2 복수의 리소스들을 갖는 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템으로서,
    프로세서를 포함하고,
    상기 프로세서는,
    상기 제 1 프로세서에 의해 제어되는 제 1 노드를 인스턴스화하는 것으로서, 상기 제 1 노드는 상기 제 2 프로세서에 의해 제어되는 제 2 노드에 대응하고, 상기 제 1 복수의 리소스들은 제 1 방향성 비순환 그래프에 의해 정의되고, 상기 제 2 복수의 리소스들은 상기 제 1 방향성 비순환 그래프와 어떤 리소스들도 공유하지 않는 제 2 방향성 비순환 그래프에 의해 정의되며, 상기 제 1 방향성 비순환 그래프의 각 노드는 상기 제 1 프로세서에 의해 제어되는 하나 이상의 리소스들의 기능성의 캡슐화를 나타내고, 상기 제 1 방향성 비순환 그래프의 각 에지는 클라이언트 요청을 나타내고, 상기 제 1 방향성 비순환 그래프의 인접 노드들은 리소스 의존성들을 나타내며, 상기 제 2 방향성 비순환 그래프의 각 노드는 상기 제 2 프로세서에 의해 제어되는 하나 이상의 리소스들의 기능성의 캡슐화를 나타내고, 상기 제 2 방향성 비순환 그래프의 각 에지는 클라이언트 요청을 나타내고, 상기 제 2 방향성 비순환 그래프의 인접 노드들은 리소스 의존성들을 나타내는, 상기 제 1 프로세서에 의해 제어되는 제 1 노드를 인스턴스화하고;
    상기 제 1 프로세서의 제어하에, 클라이언트로부터 클라이언트 요청을 상기 제 1 노드에서 수신하며; 그리고
    상기 제 1 노드에서의 클라이언트 요청에 응답하여 상기 제 2 노드에서 클라이언트 요청을 발행하도록
    동작가능한, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  9. 제 8 항에 있어서,
    상기 제 1 노드는 프로토콜 리소스에 의존하고, 상기 제 1 노드는 상기 프로토콜 리소스에 의해 정의된 전송 프로토콜을 호출하는 드라이버를 포함하도록 인스턴스화되며, 상기 드라이버는 상기 제 2 노드에서의 클라이언트 요청을 상기 전송 프로토콜에 순응시키는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  10. 제 9 항에 있어서,
    상기 제 1 노드는 상기 프로토콜 리소스가 인스턴스화되고 상기 제 2 노드가 인스턴스화될 때까지 인스턴스화되지 않는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  11. 제 8 항에 있어서,
    상기 프로세서는 추가로,
    상기 제 1 노드에서 복수의 클라이언트 요청들을 수신하고; 그리고
    수신된 상기 복수의 클라이언트 요청들을 상기 제 1 노드가 집합하여 집합 결과를 제공하도록 동작가능하며,
    상기 제 2 노드에서 클라이언트 요청을 발행하는 것은 상기 집합 결과에 대한 클라이언트 요청을 발행하는 것을 포함하는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  12. 제 8 항에 있어서,
    상기 프로세서는 추가로,
    상기 제 1 노드에서 복수의 클라이언트 요청들을 수신하는 것으로서, 상기 제 2 노드에서 클라이언트 요청을 발행하는 것은 상기 제 1 노드에서 발행된 상기 복수의 클라이언트 요청들에 대응하는 복수의 클라이언트 요청을 상기 제 2 노드에서 발행하는 것을 포함하는, 상기 제 1 노드에서 복수의 클라이언트 요청들을 수신하고; 그리고
    상기 제 2 노드에서 발행된 상기 복수의 클라이언트 요청들을 상기 제 2 노드가 집합하여 집합 결과를 제공하도록
    동작가능한, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  13. 제 8 항에 있어서,
    상기 프로세서는 추가로,
    상기 제 1 프로세서의 제어하에 클라이언트로부터 제 1 상태 쿼리를 상기 제 1 노드에서 수신하고;
    상기 제 2 노드의 상태의 표시를 획득하기 위해, 상기 제 2 노드에서 제 2 상태 쿼리를 발행하며; 그리고
    상기 제 1 상태 쿼리에 응답하여 상기 제 2 노드의 상태의 표시를 상기 제 1 노드가 제공하도록
    동작가능한, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  14. 제 8 항에 있어서,
    상기 프로세서는 추가로,
    상기 제 1 프로세서의 제어하에 클라이언트로부터 제 1 상태 쿼리를 상기 제 1 노드에서 수신하고;
    상기 제 1 상태 쿼리에 응답하여 상기 제 1 노드의 상태의 표시를 상기 제 1 노드가 제공하고;
    상기 제 2 노드의 상태에서의 변화를 검출하며; 그리고
    상기 제 2 노드의 상태에서의 변화의 검출에 응답하여 상기 제 2 노드의 상태의 표시를 상기 제 1 노드에 제공하도록
    동작가능한, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  15. 제 1 프로세서에 의해 제어되는 제 1 복수의 리소스들 및 제 2 프로세서에 의해 제어되는 제 2 복수의 리소스들을 갖는 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템으로서,
    상기 제 1 프로세서에 의해 제어되는 제 1 노드를 인스턴스화하는 수단으로서, 상기 제 1 노드는 상기 제 2 프로세서에 의해 제어되는 제 2 노드에 대응하고, 상기 제 1 복수의 리소스들은 제 1 방향성 비순환 그래프에 의해 정의되고, 상기 제 2 복수의 리소스들은 상기 제 1 방향성 비순환 그래프와 어떤 리소스들도 공유하지 않는 제 2 방향성 비순환 그래프에 의해 정의되며, 상기 제 1 방향성 비순환 그래프의 각 노드는 상기 제 1 프로세서에 의해 제어되는 하나 이상의 리소스들의 기능성의 캡슐화를 나타내고, 상기 제 1 방향성 비순환 그래프의 각 에지는 클라이언트 요청을 나타내고, 상기 제 1 방향성 비순환 그래프의 인접 노드들은 리소스 의존성들을 나타내며, 상기 제 2 방향성 비순환 그래프의 각 노드는 상기 제 2 프로세서에 의해 제어되는 하나 이상의 리소스들의 기능성의 캡슐화를 나타내고, 상기 제 2 방향성 비순환 그래프의 각 에지는 클라이언트 요청을 나타내며, 상기 제 2 방향성 비순환 그래프의 인접 노드들은 리소스 의존성들을 나타내는, 상기 제 1 프로세서에 의해 제어되는 제 1 노드를 인스턴스화하는 수단;
    상기 제 1 프로세서의 제어하에, 클라이언트로부터 클라이언트 요청을 상기 제 1 노드에서 수신하는 수단; 및
    상기 제 1 노드에서의 클라이언트 요청에 응답하여 상기 제 2 노드에서 클라이언트 요청을 발행하는 수단을 포함하는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  16. 제 15 항에 있어서,
    상기 제 1 노드는 프로토콜 리소스에 의존하고, 상기 제 1 노드는 상기 프로토콜 리소스에 의해 정의된 전송 프로토콜을 호출하는 드라이버를 포함하도록 인스턴스화되며, 상기 드라이버는 상기 제 2 노드에서의 클라이언트 요청을 상기 전송 프로토콜에 순응시키는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  17. 제 16 항에 있어서,
    상기 제 1 노드는 상기 프로토콜 리소스가 인스턴스화되고 상기 제 2 노드가 인스턴스화될 때까지 인스턴스화되지 않는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  18. 제 15 항에 있어서,
    상기 제 1 노드에서 복수의 클라이언트 요청들을 수신하는 수단; 및
    수신된 상기 복수의 클라이언트 요청들을 상기 제 1 노드가 집합하여 집합 결과를 제공하는 수단을 더 포함하며,
    상기 제 2 노드에서 클라이언트 요청을 발행하는 것은 상기 집합 결과에 대한 클라이언트 요청을 발행하는 것을 포함하는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  19. 제 15 항에 있어서,
    상기 제 1 노드에서 복수의 클라이언트 요청들을 수신하는 수단으로서, 상기 제 2 노드에서 클라이언트 요청을 발행하는 것은 상기 제 1 노드에서 발행된 상기 복수의 클라이언트 요청들에 대응하는 복수의 클라이언트 요청을 상기 제 2 노드에서 발행하는 것을 포함하는, 상기 제 1 노드에서 복수의 클라이언트 요청들을 수신하는 수단; 및
    상기 제 2 노드에서 발행된 상기 복수의 클라이언트 요청들을 상기 제 2 노드가 집합하여 집합 결과를 제공하는 수단을 더 포함하는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  20. 제 15 항에 있어서,
    상기 제 1 프로세서의 제어하에 클라이언트로부터 제 1 상태 쿼리를 상기 제 1 노드에서 수신하는 수단;
    상기 제 2 노드의 상태의 표시를 획득하기 위해, 상기 제 2 노드에서 제 2 상태 쿼리를 발행하는 수단; 및
    상기 제 1 상태 쿼리에 응답하여 상기 제 2 노드의 상태의 표시를 상기 제 1 노드가 제공하는 수단을 더 포함하는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  21. 제 15 항에 있어서,
    상기 제 1 프로세서의 제어하에 클라이언트로부터 제 1 상태 쿼리를 상기 제 1 노드에서 수신하는 수단;
    상기 제 1 상태 쿼리에 응답하여 상기 제 1 노드의 상태의 표시를 상기 제 1 노드가 제공하는 수단;
    상기 제 2 노드의 상태에서의 변화를 검출하는 수단; 및
    상기 제 2 노드의 상태에서의 변화의 검출에 응답하여 상기 제 2 노드의 상태의 표시를 상기 제 1 노드에 제공하는 수단을 더 포함하는, 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리를 위한 컴퓨터 시스템.
  22. 컴퓨터 판독가능 프로그램 코드가 내부에 수록된 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품으로서,
    상기 컴퓨터 판독가능 프로그램 코드는 휴대용 컴퓨팅 디바이스의 리소스들을 관리하는 방법을 구현하기 위해 실행되도록 구성되며,
    상기 휴대용 컴퓨팅 디바이스의 리소스들을 관리하는 방법은,
    상기 제 1 프로세서에 의해 제어되는 제 1 노드를 인스턴스화하는 단계로서, 상기 제 1 노드는 상기 제 2 프로세서에 의해 제어되는 제 2 노드에 대응하고, 상기 제 1 복수의 리소스들은 제 1 방향성 비순환 그래프에 의해 정의되고, 상기 제 2 복수의 리소스들은 상기 제 1 방향성 비순환 그래프와 어떤 리소스들도 공유하지 않는 제 2 방향성 비순환 그래프에 의해 정의되며, 상기 제 1 방향성 비순환 그래프의 각 노드는 상기 제 1 프로세서에 의해 제어되는 하나 이상의 리소스들의 기능성의 캡슐화를 나타내고, 상기 제 1 방향성 비순환 그래프의 각 에지는 클라이언트 요청을 나타내고, 상기 제 1 방향성 비순환 그래프의 인접 노드들은 리소스 의존성들을 나타내며, 상기 제 2 방향성 비순환 그래프의 각 노드는 상기 제 2 프로세서에 의해 제어되는 하나 이상의 리소스들의 기능성의 캡슐화를 나타내고, 상기 제 2 방향성 비순환 그래프의 각 에지는 클라이언트 요청을 나타내고, 상기 제 2 방향성 비순환 그래프의 인접 노드들은 리소스 의존성들을 나타내는, 상기 제 1 프로세서에 의해 제어되는 제 1 노드를 인스턴스화하는 단계;
    상기 제 1 프로세서의 제어하에, 클라이언트로부터 클라이언트 요청을 상기 제 1 노드에서 수신하는 단계; 및
    상기 제 1 노드에서의 클라이언트 요청에 응답하여 상기 제 2 노드에서 클라이언트 요청을 발행하는 단계를 포함하는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  23. 제 22 항에 있어서,
    상기 제 1 노드는 프로토콜 리소스에 의존하고, 상기 제 1 노드는 상기 프로토콜 리소스에 의해 정의된 전송 프로토콜을 호출하는 드라이버를 포함하도록 인스턴스화되며, 상기 드라이버는 상기 제 2 노드에서의 클라이언트 요청을 상기 전송 프로토콜에 순응시키는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  24. 제 23 항에 있어서,
    상기 제 1 노드는 상기 프로토콜 리소스가 인스턴스화되고 상기 제 2 노드가 인스턴스화될 때까지 인스턴스화되지 않는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  25. 제 22 항에 있어서,
    상기 휴대용 컴퓨팅 디바이스의 리소스들을 관리하는 방법은,
    상기 제 1 노드에서 복수의 클라이언트 요청들을 수신하는 단계; 및
    수신된 상기 복수의 클라이언트 요청들을 상기 제 1 노드가 집합하여 집합 결과를 제공하는 단계
    를 더 포함하며,
    상기 제 2 노드에서 클라이언트 요청을 발행하는 단계는 상기 집합 결과에 대한 클라이언트 요청을 발행하는 단계를 포함하는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  26. 제 22 항에 있어서,
    상기 휴대용 컴퓨팅 디바이스의 리소스들을 관리하는 방법은,
    상기 제 1 노드에서 복수의 클라이언트 요청들을 수신하는 단계로서, 상기 제 2 노드에서 클라이언트 요청을 발행하는 단계는 상기 제 1 노드에서 발행된 상기 복수의 클라이언트 요청들에 대응하는 복수의 클라이언트 요청을 상기 제 2 노드에서 발행하는 단계를 포함하는, 상기 제 1 노드에서 복수의 클라이언트 요청들을 수신하는 단계; 및
    상기 제 2 노드에서 발행된 상기 복수의 클라이언트 요청들을 상기 제 2 노드가 집합하여 집합 결과를 제공하는 단계
    를 더 포함하는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  27. 제 22 항에 있어서,
    상기 휴대용 컴퓨팅 디바이스의 리소스들을 관리하는 방법은,
    상기 제 1 프로세서의 제어하에 클라이언트로부터 제 1 상태 쿼리를 상기 제 1 노드에서 수신하는 단계;
    상기 제 2 노드의 상태의 표시를 획득하기 위해, 상기 제 2 노드에서 제 2 상태 쿼리를 발행하는 단계; 및
    상기 제 1 상태 쿼리에 응답하여 상기 제 2 노드의 상태의 표시를 상기 제 1 노드가 제공하는 단계
    를 더 포함하는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  28. 제 22 항에 있어서,
    상기 휴대용 컴퓨팅 디바이스의 리소스들을 관리하는 방법은,
    상기 제 1 프로세서의 제어하에 클라이언트로부터 제 1 상태 쿼리를 상기 제 1 노드에서 수신하는 단계;
    상기 제 1 상태 쿼리에 응답하여 상기 제 1 노드의 상태의 표시를 상기 제 1 노드가 제공하는 단계;
    상기 제 2 노드의 상태에서의 변화를 검출하는 단계; 및
    상기 제 2 노드의 상태에서의 변화의 검출에 응답하여 상기 제 2 노드의 상태의 표시를 상기 제 1 노드에 제공하는 단계
    를 더 포함하는, 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품.


KR1020147008825A 2011-09-02 2012-08-14 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리 KR101618476B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/225,152 2011-09-02
US13/225,152 US8631414B2 (en) 2010-09-15 2011-09-02 Distributed resource management in a portable computing device
PCT/US2012/050815 WO2013032694A1 (en) 2011-09-02 2012-08-14 Distributed resource management in a portable computing device

Publications (2)

Publication Number Publication Date
KR20140057649A true KR20140057649A (ko) 2014-05-13
KR101618476B1 KR101618476B1 (ko) 2016-05-04

Family

ID=46763179

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147008825A KR101618476B1 (ko) 2011-09-02 2012-08-14 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리

Country Status (7)

Country Link
US (1) US8631414B2 (ko)
EP (1) EP2751686A1 (ko)
JP (1) JP5969610B2 (ko)
KR (1) KR101618476B1 (ko)
CN (1) CN103765387B (ko)
IN (1) IN2014CN00929A (ko)
WO (1) WO2013032694A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160037737A (ko) * 2014-09-29 2016-04-06 삼성전자주식회사 스케쥴러 컴퓨팅 장치, 그것을 포함하는 분산 컴퓨팅 시스템의 데이터 노드 및 그것의 방법
KR20180061329A (ko) * 2015-10-01 2018-06-07 이베이 인크. 개념 그래프 생성하기

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8615755B2 (en) 2010-09-15 2013-12-24 Qualcomm Incorporated System and method for managing resources of a portable computing device
US8806502B2 (en) 2010-09-15 2014-08-12 Qualcomm Incorporated Batching resource requests in a portable computing device
US9098521B2 (en) 2010-09-15 2015-08-04 Qualcomm Incorporated System and method for managing resources and threshsold events of a multicore portable computing device
US9152523B2 (en) 2010-09-15 2015-10-06 Qualcomm Incorporated Batching and forking resource requests in a portable computing device
US9870298B2 (en) 2013-08-26 2018-01-16 Google Llc Application resource utilization management
CN105306223A (zh) * 2014-06-30 2016-02-03 中兴通讯股份有限公司 供电方法、装置及系统
US9330199B2 (en) 2014-07-21 2016-05-03 Facebook, Inc. Striping of directed graphs and nodes with improved functionality
US20180121891A1 (en) * 2016-11-02 2018-05-03 Mastercard International Incorporated System and method for processing payment transactions at network edge nodes
US20180204159A1 (en) 2017-01-19 2018-07-19 Bank Of America Corporation Resource and experience factor value generation system
CN108664335B (zh) * 2017-04-01 2020-06-30 北京忆芯科技有限公司 通过代理进行队列通信的方法与装置
CN108388470B (zh) * 2018-01-26 2022-09-16 福建星瑞格软件有限公司 一种大数据任务处理方法及计算机设备
WO2022027600A1 (zh) * 2020-08-07 2022-02-10 厦门雅基软件有限公司 游戏引擎资源处理方法及其装置、电子设备及计算机可读存储介质

Family Cites Families (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995010805A1 (en) 1993-10-08 1995-04-20 International Business Machines Corporation Message transmission across a network
US5668993A (en) 1994-02-28 1997-09-16 Teleflex Information Systems, Inc. Multithreaded batch processing system
US6574654B1 (en) 1996-06-24 2003-06-03 Oracle Corporation Method and apparatus for lock caching
US6715145B1 (en) 1999-08-31 2004-03-30 Accenture Llp Processing pipeline in a base services pattern environment
WO2001035278A1 (en) 1999-11-10 2001-05-17 Fakhouri Sameh A A decision based system for managing distributed resources and modeling the global optimization problem
US6571354B1 (en) 1999-12-15 2003-05-27 Dell Products, L.P. Method and apparatus for storage unit replacement according to array priority
US7117273B1 (en) 2000-01-25 2006-10-03 Cisco Technology, Inc. Methods and apparatus for maintaining a map of node relationships for a network
US6799208B1 (en) 2000-05-02 2004-09-28 Microsoft Corporation Resource manager architecture
US7050807B1 (en) 2000-06-12 2006-05-23 General Dynamics Decision Systems, Inc. Hardware resource identifier for software-defined communications system
US20020087734A1 (en) 2000-12-29 2002-07-04 Marshall Donald Brent System and method for managing dependencies in a component-based system
US6901446B2 (en) 2001-02-28 2005-05-31 Microsoft Corp. System and method for describing and automatically managing resources
JP2003076563A (ja) * 2001-06-15 2003-03-14 Ntt Software Corp 分散オブジェクトミドルウェア連携方法及びプログラムを記録した記録媒体並びにプログラム
US6971098B2 (en) 2001-06-27 2005-11-29 Intel Corporation Method and apparatus for managing transaction requests in a multi-node architecture
US7114158B1 (en) 2001-10-01 2006-09-26 Microsoft Corporation Programming framework including queueing network
US6931355B2 (en) 2002-02-26 2005-08-16 Xerox Corporation Method and apparatus for providing data logging in a modular device
US7150014B2 (en) 2002-10-04 2006-12-12 Hewlett-Packard Development Company, L.P. Automatically deploying software packages used in computer systems
US7152157B2 (en) 2003-03-05 2006-12-19 Sun Microsystems, Inc. System and method for dynamic resource configuration using a dependency graph
US7334230B2 (en) 2003-03-31 2008-02-19 International Business Machines Corporation Resource allocation in a NUMA architecture based on separate application specified resource and strength preferences for processor and memory resources
GB2408361B (en) 2003-11-21 2007-07-25 Symbian Ltd Allocation of resources in a computing device
US20050183143A1 (en) 2004-02-13 2005-08-18 Anderholm Eric J. Methods and systems for monitoring user, application or device activity
US7478361B2 (en) 2004-06-17 2009-01-13 International Business Machines Corporation Method and system for managing application deployment
US7849459B2 (en) 2004-11-04 2010-12-07 International Business Machines Corporation Deploying java applications in resource constrained environments
US20060150188A1 (en) 2004-12-21 2006-07-06 Manuel Roman Method and apparatus for supporting soft real-time behavior
EP1715405A1 (en) 2005-04-19 2006-10-25 STMicroelectronics S.r.l. Processing method, system and computer program product for dynamic allocation of processing tasks in a multiprocessor cluster platforms with power adjustment
US20070136725A1 (en) 2005-12-12 2007-06-14 International Business Machines Corporation System and method for optimized preemption and reservation of software locks
US20070168244A1 (en) * 2006-01-19 2007-07-19 International Business Machines Corporation Methods and apparatus for coordinating and selecting protocols for resources acquisition from multiple resource managers
US20070294364A1 (en) 2006-06-15 2007-12-20 International Business Machines Corporation Management of composite software services
US7814486B2 (en) 2006-06-20 2010-10-12 Google Inc. Multi-thread runtime system
US7711946B2 (en) 2006-08-07 2010-05-04 Oracle America, Inc. Method and apparatus for using filesystem operations to initiate device naming
GB2443229B (en) 2006-08-23 2009-10-14 Cramer Systems Ltd Capacity management for data networks
US8954045B2 (en) 2006-09-29 2015-02-10 Qualcomm Incorporated Method and apparatus for managing resources at a wireless device
US7577658B2 (en) 2006-10-06 2009-08-18 Microsoft Corporation Hierarchical locking in B-tree indexes
US8209703B2 (en) * 2006-12-08 2012-06-26 SAP France S.A. Apparatus and method for dataflow execution in a distributed environment using directed acyclic graph and prioritization of sub-dataflow tasks
EP1933237A1 (de) 2006-12-15 2008-06-18 Ubs Ag Computerimplementiertes System zur Analyse, Verwaltung, Beherrschung, Bewirtschaftung und Überwachung einer komplexen Hardware-/Softwarearchitektur
JP2008226181A (ja) 2007-03-15 2008-09-25 Fujitsu Ltd 並列実行プログラム、該プログラムを記録した記録媒体、並列実行装置および並列実行方法
US20080244507A1 (en) 2007-03-30 2008-10-02 Microsoft Corporation Homogeneous Programming For Heterogeneous Multiprocessor Systems
US8789063B2 (en) 2007-03-30 2014-07-22 Microsoft Corporation Master and subordinate operating system kernels for heterogeneous multiprocessor systems
US20080294777A1 (en) 2007-05-25 2008-11-27 Alexei Karve Method and apparatus for template-based provisioning in a service delivery environment
US8042122B2 (en) 2007-06-27 2011-10-18 Microsoft Corporation Hybrid resource manager
US8429645B2 (en) 2007-08-14 2013-04-23 International Business Machines Corporation Method for optimizing migration of software applications to address needs
US20090094126A1 (en) 2007-10-03 2009-04-09 Patrick Killian Dual use point of sale terminal and methods of operating same
CN101442475A (zh) * 2007-11-24 2009-05-27 华为技术有限公司 一种分布式业务代理的方法、网络系统与网络设备
US8196142B2 (en) 2007-12-18 2012-06-05 Oracle America, Inc. Use of external services with clusters
GB0811943D0 (en) 2008-06-30 2008-07-30 Symbian Software Ltd Computing device
CN101384015B (zh) * 2008-09-28 2011-11-16 华为技术有限公司 一种分布式电信设备及分布式电信设备处理业务的方法
GB2465785B (en) 2008-11-28 2012-07-04 Vmware Inc Computer system and method for resolving dependencies in a computer system
GB2465784B (en) 2008-11-28 2012-07-11 Vmware Inc Computer system and method for configuring an application program in a computer system
US20100162247A1 (en) 2008-12-19 2010-06-24 Adam Welc Methods and systems for transactional nested parallelism
US8510744B2 (en) 2009-02-24 2013-08-13 Siemens Product Lifecycle Management Software Inc. Using resource defining attributes to enhance thread scheduling in processors
SG166014A1 (en) 2009-04-14 2010-11-29 Electron Database Corp Pte Ltd Server architecture for multi-core systems
US8543800B2 (en) * 2009-06-10 2013-09-24 International Business Machines Corporation Hierarchical services startup sequencing
US8302105B2 (en) 2009-06-26 2012-10-30 Oracle America, Inc. Bulk synchronization in transactional memory systems
US8032682B2 (en) 2009-07-13 2011-10-04 Oracle America, Inc. System and method for device resource allocation and re-balance
US8321870B2 (en) 2009-08-14 2012-11-27 General Electric Company Method and system for distributed computation having sub-task processing and sub-solution redistribution
US8793690B2 (en) * 2009-10-09 2014-07-29 International Business Machines Corporation Generating timing sequence for activating resources linked through time dependency relationships
US8375175B2 (en) 2009-12-09 2013-02-12 Oracle America, Inc. Fast and efficient reacquisition of locks for transactional memory systems
US8745629B2 (en) * 2010-01-11 2014-06-03 Qualcomm Incorporated System and method of controlling power in an electronic device
US8510751B2 (en) * 2010-03-18 2013-08-13 International Business Machines Corporation Optimizing workflow engines
US9098521B2 (en) 2010-09-15 2015-08-04 Qualcomm Incorporated System and method for managing resources and threshsold events of a multicore portable computing device
US9152523B2 (en) 2010-09-15 2015-10-06 Qualcomm Incorporated Batching and forking resource requests in a portable computing device
US8615755B2 (en) 2010-09-15 2013-12-24 Qualcomm Incorporated System and method for managing resources of a portable computing device
US8806502B2 (en) 2010-09-15 2014-08-12 Qualcomm Incorporated Batching resource requests in a portable computing device
US8694981B2 (en) 2010-11-17 2014-04-08 Apple Inc. Shared resource dependencies

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160037737A (ko) * 2014-09-29 2016-04-06 삼성전자주식회사 스케쥴러 컴퓨팅 장치, 그것을 포함하는 분산 컴퓨팅 시스템의 데이터 노드 및 그것의 방법
KR20180061329A (ko) * 2015-10-01 2018-06-07 이베이 인크. 개념 그래프 생성하기

Also Published As

Publication number Publication date
US8631414B2 (en) 2014-01-14
CN103765387B (zh) 2017-04-05
JP5969610B2 (ja) 2016-08-17
JP2014528116A (ja) 2014-10-23
KR101618476B1 (ko) 2016-05-04
US20120227053A1 (en) 2012-09-06
CN103765387A (zh) 2014-04-30
WO2013032694A1 (en) 2013-03-07
EP2751686A1 (en) 2014-07-09
IN2014CN00929A (ko) 2015-04-10

Similar Documents

Publication Publication Date Title
KR101618476B1 (ko) 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리
US8806502B2 (en) Batching resource requests in a portable computing device
US9152523B2 (en) Batching and forking resource requests in a portable computing device
KR101503209B1 (ko) 휴대용 컴퓨팅 디바이스의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법 및 시스템
US8615755B2 (en) System and method for managing resources of a portable computing device
US8601484B2 (en) System and method for managing resources and markers of a portable computing device
US9098521B2 (en) System and method for managing resources and threshsold events of a multicore portable computing device
US8745629B2 (en) System and method of controlling power in an electronic device
US8943504B2 (en) Tracking and releasing resources placed on a deferred unlock list at the end of a transaction
EP2751687B1 (en) Method and system for managing parallel resource requests in a portable computing device
JP5805887B2 (ja) ポータブルコンピューティングデバイスにおけるリソース要求のバッチングおよびフォーク

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
LAPS Lapse due to unpaid annual fee