KR101619002B1

KR101619002B1 - 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 시스템 및 방법

Info

Publication number: KR101619002B1
Application number: KR1020147008581A
Authority: KR
Inventors: 노먼 에스 가르가쉬; 비노드 비자야라잔
Original assignee: 퀄컴 인코포레이티드
Priority date: 2011-09-02
Filing date: 2012-08-15
Publication date: 2016-05-09
Anticipated expiration: 2032-08-15
Also published as: US9098521B2; JP2014525627A; IN2014CN01077A; KR20140056382A; US20130019249A1; EP2751680A1; WO2013032711A1; CN103782275A; JP5864754B2; CN103782275B

Abstract

휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법 및 시스템이 개시된다. 이 방법은 노드를 형성하기 위한 노드 구조 데이터를 수신하는 것을 포함하고, 노드 구조 데이터는 노드의 일부인 각각의 리소스에 대한 고유 명칭 (unique name) 을 포함한다. 노드는 적어도 하나의 리소스를 구비하고 다수의 리소스드을 구비할 수도 있다. 각각의 리소스는 하드웨어 또는 소프트웨어 엘리먼트일 수도 있다. 시스템은 노드 아키텍쳐 내에서 현존하는 노드들 사이의 통신들을 핸들링하는 프레임워크 매니저를 포함한다. 프레임워크 매니저는 각 리소스의 고유 명칭을 사용하는 것에 의해 각 리소스의 액티비티를 또한 로깅한다. 프레임워크 매니저는 이 로깅된 액티비티를, 프린터 또는 디스플레이 스크린과 같은 출력 디바이스로 전송할 수도 있다. 이 방법 및 시스템은, 새로운 하드웨어 또는 소프트웨어 엘리먼트 (또는 양자) 가 휴대형 컴퓨팅 디바이스에 추가된 경우 커스터마이징된 API들에 대한 필요성을 감소시키거나 제거하는 데 도움이 될 수도 있다.

Description

휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 시스템 및 방법{SYSTEM AND METHOD FOR MANAGING RESOURCES OF A PORTABLE COMPUTING DEVICE}

관련 기술의 설명

휴대형 컴퓨팅 디바이스들 (Portable computing devices; PCD들) 은 개인적 레벨과 전문가적 레벨의 사람들에 대해 개인적 필수품들이 되고 있다. 이들 디바이스들은 셀룰러 전화기들, PDA들 (Portable Digital Assistants; 개인 휴대 정보 단말기들), 휴대형 게임 콘솔들, 팜탑 컴퓨터들, 및 다른 휴대형 전자 디바이스들을 포함할 수도 있다. 이들 디바이스들의 각각은 주 기능을 포함할 수도 있다. 예를 들면, 셀룰러 전화기는 일반적으로 전화 호들을 수신하고 송신하는 주 기능을 갖는다.

이들 디바이스들의 주 기능에 더하여, 많은 것들이 주변 기능들을 포함한다. 예를 들면, 셀룰러 전화기는 상술한 바와 같이 셀룰러 전화 호들을 행하는 주 기능, 및 스틸 카메라, 비디오 카메라, GPS (global positioning system) 내비게이션, 웹브라우징, 이메일들 송수신, 문자 메시지들 송수신, 푸시투토크 성능들 등의 부 기능들을 포함할 수도 있다. 이러한 디바이스의 기능들이 증가함에 따라, 이러한 기능들을 지원하는 데 필요한 컴퓨팅 또는 프로세싱 파워도 또한 증가한다. 또한, 컴퓨팅 파워가 증가함에 따라, 컴퓨팅 파워를 제공하는 프로세서 또는 프로세서들을 효율적으로 관리할 필요가 더 커진다.

과거, 하드웨어 또는 소프트웨어 (또는 양자) 에 의해 지원된 각각의 주변 기능이 셀룰러 전화기와 같은 디바이스에 도입될 때, 특정 어플리케이션 프로그래밍 인터페이스 (application programming interface; API) 가 각각의 주변 기능에 대해 도입되었다. 예를 들면, 비디오 카메라에 대해 별개의 API가 존재하고 GPS 내비게이션 어플리케이션 소프트웨어에 대해 별개의 API가 존재할 수도 있다. 각각의 API는 일반적으로 자신의 액션들을 독립적으로 로깅했고 각각의 API는 일반적으로 자기 자신의 데이터 구조를 구비하는데, 이 데이터 구조는, 새로운 주변 기능의 도입 이전에 존재했던 셀룰러 전화기의 기존의 하드웨어 또는 소프트웨어를 교차참조하는 것을 필요로 할 것이다.

각각의 주변 기능에 대한 별도의 API들의 도입은 아주 성가신 일이며 시간 소모적인데, 그 이유는 상이한 하드웨어 및 소프트웨어 엘리먼트들에 대한 교차참조 때문이다. 셀룰러 전화기의 기본 기능들을 지원하는 각각의 하드웨어 또는 소프트웨어는 셀룰러 전화기의 주문자 상표 부착생산자 (original equipment manufacturer; OEM) 및/또는 셀룰러 전화기의 기본 기능들을 지원하는 근본적인 전자부품의 OEM에 의해 확립된 명칭을 제공받을 수도 있다. 소프트웨어 또는 하드웨어 (또는 양자) 와 관련된 새로운 피쳐들 또는 기능들의 로깅 (logging) 및 디버깅은, 이 휴대형 컴퓨팅 디바이스 기술분야의 당업자들에 의해, 새로운 제품들 또는 피쳐들 (또는 양자) 를 제공함에 있어서 중요한 문제로서 오랫동안 인식되어 왔다.

OEM들에 의해 세워진 시스템들에 추가되는 새로운 소프트웨어 또는 하드웨어 (또는 양자) 에 의해 지원되는 새로운 피쳐들 또는 기능들을 도입하는 것에 관련된 문제점들을 극복할 수도 있는 시스템 및 방법을 제공하는 것이 필요하다.

본 개시의 개요

휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법 및 시스템이 설명되는데, 시스템 및 방법은 노드를 형성하기 위한 노드 구조 데이터를 수신하는 것을 포함하며, 노드 구조 데이터는 노드의 일부인 각각의 리소스에 대한 고유 명칭을 포함한다. 다음에, 하나 이상의 의존성들에 대해 노드 구조 데이터가 리뷰될 수도 있다. 그 다음, 인스턴스화되지 않은 노드에 대한 의존성과 관련된 각각의 리소스가 노드 프레임워크 내에 존재하는지 아닌지가 결정된다.

이 방법 및 시스템은 인스턴스화되지 않은 노드의 각 리소스가 요청을 지원하는 데 이용가능한지 아닌지를 결정하는 것을 또한 포함할 수도 있다. 인스턴스화되지 않은 노드의 리소스가 임의의 요청들을 지원하는 데 이용가능하지 않으면, 이용가능하지 않은 리소스를 포함하는 노드의 인스턴스화를 방지하기 위한 값이 설정될 수도 있다. 이용가능하지 않은 리소스는 접속가능한 하드웨어를 포함할 수도 있는데, 이것은 PCD로부터 제거될 수 있다.

의존성과 관련된 리소스가 전혀 존재하지 않으면, 노드 구조 데이터는 임시 스토리지에 저장될 수도 있다. 노드 구조 데이터 내에 각각의 의존성에 대한 각 리소스가 존재하고 이용가능하면, 자신의 하나 이상의 리소스들을 갖는 노드는 생성되거나 인스턴스화될 수도 있다. 노드가 생성/인스턴스화되면, 노드는 통신들을 프로세싱하도록 준비된 상태에 있는 노드의 하나 이상의 리소스들에 대응하는 하나 이상의 고유 명칭들을 사용하여 노드 프레임워크 내에서 공표 (publish) 될 수도 있다.

이 방법 및 시스템은 인스턴스화된 노드의 각 리소스가 요청을 지원하는 데 이용가능한지 아닌지를 결정하는 것을 더 포함할 수도 있다. 인스턴스화 노드의 리소스가 임의의 요청들을 지원하는 데 이용가능하지 않으면, 인스턴스화된 노드는 다른 리소스들에 의한 액세스로부터 락 (lock) 될 수도 있다.

이 방법 및 시스템은 노드 프레임워크에서 플레이스홀더 (placeholder) 로서 기능하는 스터브 리소스를 형성하기 위한 데이터를 수신하는 것을 더 포함할 수도 있다. 스터브 데이터를 수신한 이후, 이 방법 및 시스템은 기능적 리소스로 스터브 리소스를 대체하기 위한 데이터를 수신할 수도 있고, 그 결과, 노드 프레임워크는 기능적 노드들만을 포함하도록 완성될 수도 있다.

이 방법 및 시스템은, 파워 및/또는 성능을 향상시키기 위해, 노드 프레임워크 내에서 관리되는 클라이언트 요청이 지연된 실행을 위해 억제가능한지 아닌지를 결정하는 것을 더 포함할 수도 있다. 이 방법 및 시스템은 억제가능한 요청들에 대한 실행을 지연시키기 위해 하나 이상의 조건들이 달성되었는지 아닌지를 결정하는 것을 더 포함할 수도 있다.

이 방법 및 시스템은 리소스에 의한 관리를 위해 하나 이상의 임계치 이벤트들을 수신하는 것을 더 포함할 수도 있다. 각각의 임계치 이벤트는 리소스에 의해 추적되는 적어도 하나의 조건을 구비할 수도 있다.

도면들에서, 다르게 특정되지 않는 한, 유사한 도면 번호들은 도면 전체에 걸쳐 유사한 부분들을 가리킨다. "102A" 또는 "102B"와 같은 문자 지정들을 갖는 도면 번호들에 있어서, 문자 지정들은 동일한 도면에 존재하는 2개의 유사한 부분들 또는 엘리먼트들을 차별화할 수도 있다. 도면 번호들에 대한 문자 지정들은, 모든 도면들에서 도면 번호가 동일한 도면 번호를 갖는 모든 부분들을 포괄하는 것이 의도되는 경우 생략될 수도 있다.
도 1은 닫힌 위치에 있는 휴대형 컴퓨팅 디바이스 (PCD) 의 제 1의 양태의 정면도이다;
도 2는 열린 위치의 PCD의 제 1의 양태의 정면도이다;
도 3은 PCD의 제 2의 양태의 블록도이다;
도 4는 프로세싱 시스템의 블록도이다;
도 5는 도 1의 휴대형 컴퓨팅 디바이스의 리소스들을 관리하는 시스템에 대한 소프트웨어 아키텍쳐의 제 1의 양태의 도면이다;
도 6a는 도 1의 PCD의 리소스들을 관리하는 시스템에 대한 소프트웨어 아키텍쳐의 제 2의 양태를 제공하는 노드 또는 리소스 그래프의 도면이다;
도 6b는 특정적이며 여전히 예시적인 리소스 명칭들을 갖는 노드들을 포함하는 노드 또는 리소스 그래프의 도면이다;
도 6c는 소프트웨어 아키텍쳐의 리소스들에 대해 추적될 수도 있는 예시적인 온도 임계치 이벤트들을 도시하는 도면이다;
도 6d는 리소스들 및 도 6c의 온도 임계치 이벤트들에 대응할 수도 있고 각각의 리소스에 의해 추적될 수도 있는 대응하는 예시적인 온도 이벤트들의 차트를 도시하는 도면이다;
도 7a는 PCD의 리소스(들) 을 관리하기 위한 소프트웨어 아키텍쳐를 생성하는 방법을 도시하는 흐름도이다;
도 7b는 PCD의 리소스(들) 을 관리하기 위한 소프트웨어 아키텍쳐를 생성하는 방법을 도시하는 도 7a의 계속 흐름도이다;
도 7c는 PCD에 대해 이용불가능하게 된 인스턴스화되지 않은 노드들을 관리하기 위한 방법을 도시하는 도 7a의 계속 흐름도이다;
도 7d는 PCD에 대한 억제가능한 요청들을 관리하는 방법을 도시하는 도 7b의 계속 흐름도이다;
도 7e는 PCD에 이용불가능하게 된 인스턴스화된 노드들을 관리하기 위한 방법을 도시하는 도 7b의 계속 흐름도이다;
도 8은 PCD에서의 소프트웨어 아키텍쳐에서 노드 구조 데이터를 수신하기 위한 도 7a 및 도 7b의 서브 방법 또는 루틴을 도시하는 흐름도이다;
도 9는 PCD에 대한 소프트웨어 아키텍쳐에서 노드를 생성하기 위한 도 7a 및 도 7b의 서브 방법 또는 루틴을 도시하는 흐름도이다;
도 10은 PCD에 대한 소프트웨어 아키텍쳐에 의해 유지될 수도 있는 예시적인 명칭 테이블에 대한 데이터 구조의 도면이다;
도 11은 PCD에 대한 소프트웨어 아키텍쳐에서 리소스의 앨리어스를 생성하는 방법을 도시하는 흐름도이다;
도 12는 PCD의 소프트웨어 아키텍쳐에서 클라이언트를 생성하기 위한 도 9의 서브 방법 또는 루틴을 도시하는 흐름도이다;
도 13은 PCD에 대한 소프트웨어 아키텍쳐에서 리소스에 대한 클라이언트 요청을 생성하는 방법을 도시하는 흐름도이다;
도 14는 PCD의 리소스에 대한 등시성 클라이언트 요청에서 요청된 작업 (work) 을 도시하는 도면이다;
도 15는 PCD에 대한 소프트웨어 아키텍쳐에서 리소스에 대한 등시성 클라이언트 요청을 생성하기 위한 도 9의 서브 방법 또는 루틴을 도시하는 흐름도이다;
도 16은 PCD에 대한 소프트웨어 아키텍쳐에서 리소스에 대한 임계치 이벤트를 생성하는 방법을 도시하는 흐름도이다;
도 17은 PCD에 대한 소프트웨어 아키텍쳐에서 스터브 리소스를 새로운 (실제) 리소스로 대체하는 방법을 도시하는 흐름도이다.

상세한 설명

단어 "예시적인"은 본원에서 "실시예, 예시 또는 예증으로서 기능하는" 것을 의미하기 위해 사용된다. "예시적인"으로서 본원에서 설명된 임의의 양태는 다른 양태들에 비해 더 선호되거나 또는 더 유익한 것으로 해석될 필요는 없다.

본 설명에서, 용어 "어플리케이션"은 실행 가능한 컨텐츠, 예컨대: 오브젝트 코드, 스크립트들, 바이트 코드, 마크업 랭기지 파일들, 및 패치들을 구비하는 파일들을 또한 포함할 수도 있다. 또한, 본원에서 참조된 "어플리케이션"은, 오픈 (open) 되어야 할 필요가 있는 다큐먼트들 또는 액세스될 필요가 있는 다른 데이터 파일들과 같이, 사실상 실행 불가능한 파일들을 또한 포함할 수도 있다.

용어 "컨텐츠"는 실행 가능한 컨텐츠, 예컨대: 오브젝트 코드, 스크립트들, 바이트 코드, 마크업 랭기지 파일들, 및 패치들을 구비하는 파일들을 또한 포함할 수도 있다. 또한, 본원에서 참조된 "컨텐츠"는, 오픈되어야 할 필요가 있는 다큐먼트들 또는 액세스될 필요가 있는 다른 데이터 파일들과 같이, 사실상 실행 불가능한 파일들을 또한 포함할 수도 있다.

본원에서 사용된 바와 같이, 용어 "컴포넌트", "데이터베이스", "모듈", "시스템" 등은 컴퓨터 관련 엔티티, 즉 하드웨어, 펌웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어, 또는 실행 중인 소프트웨어 중 하나를 가리키는 것으로 의도된다. 예를 들면, 컴포넌트는 프로세서 상에서 작동하는 프로세스, 프로세서, 오브젝트, 실행가능성, 실행의 스레드, 프로그램, 및/또는 컴퓨터일 수도 있지만, 이들에 제한되는 것은 아니다. 예로서, 컴퓨팅 디바이스 상에서 작동하는 어플리케이션 및 컴퓨팅 디바이스 양자는 컴포넌트일 수도 있다. 하나 이상의 컴포넌트들은 프로세스 및/또는 실행의 스레드 내에 있을 수도 있고, 컴포넌트는 하나의 컴퓨터에 로컬라이징될 수도 있고 및/또는 두 개 이상의 컴퓨터들 사이에 분산될 수도 있다. 또한, 이들 컴포넌트들은 여러 데이터 구조들이 저장된 여러 컴퓨터 판독 가능한 매체로부터 실행될 수도 있다. 컴포넌트들은 하나 이상의 데이터 패킷들 (예를 들면, 로컬 시스템의 다른 컴포넌트, 분산 시스템 및/또는 인터넷과 같은 네트워크 전역에서 신호를 통해 다른 시스템들과 상호작용하는 하나의 컴포넌트로부터의 데이터) 을 구비하는 신호에 따르는 것과 같이 로컬 및/또는 원격 프로세스들을 통해 통신할 수도 있다.

이 설명에서, 용어 "통신 디바이스", "무선 디바이스", "무선 전화기", "무선 통신 디바이스" 및 "무선 핸드셋"은 상호교환적으로 사용된다. 3세대 ("3G") 무선 기술 및 4세대 ("4G") 무선 기술의 출현과 함께, 더 큰 대역폭의 이용가능성이, 더 다양한 무선 성능들을 갖는 더 많은 휴대형 컴퓨팅 디바이스들을 가능하게 하였다. 따라서, 휴대형 컴퓨팅 디바이스는, 셀룰러 전화기, 페이저, PDA, 스마트폰, 내비게이션 디바이스, 또는 무선 접속 또는 링크를 갖는 핸드헬드 컴퓨터일 수도 있다.

먼저, 도 1 및 도 2를 참조하면, 예시적인 휴대형 컴퓨팅 디바이스 (PCD) 가 도시되어 있고 일반적으로 100으로 나타낸다. 도시된 바와 같이, PCD (100) 는 하우징 (102) 을 포함할 수도 있다. 하우징 (102) 은 상부 하우징부 (104) 및 하부 하우징부 (106) 를 포함할 수도 있다 (도 2). 도 1은 상부 하우징부 (104) 가 디스플레이 (108) 를 포함할 수도 있음을 나타낸다. 특별한 양태에서, 디스플레이 (108) 는 터치스크린 디스플레이일 수도 있다. 상부 하우징부 (104) 는 트랙볼 입력 디바이스 (110) 를 또한 포함할 수도 있다. 또한, 도 1에 도시된 바와 같이, 상부 하우징부 (104) 는 파워 온 버튼 (112) 및 파워 오프 버튼 (114) 을 포함할 수도 있다. 도 1에 도시된 바와 같이, PCD (100) 의 상부 하우징부 (104) 는 복수의 지시 라이트들 (indicator lights; 116) 및 스피커 (118) 를 포함할 수도 있다. 각각의 지시 라이트 (116) 는 발광 다이오드 (LED) 일 수도 있다.

특별한 양태에서, 도 2에 도시된 바와 같이, 상부 하우징부 (104) 는 하부 하우징부 (106) 에 대해 이동 가능하다. 특히, 상부 하우징부 (104) 는 하부 하우징부 (106) 에 대해 슬라이드 가능할 수도 있다. 도 2에 도시된 바와 같이, 하부 하우징부 (106) 는 복수 버튼의 키보드 (120) 를 포함할 수도 있다. 특별한 양태에서, 복수 버튼의 키보드 (120) 는 표준 쿼티 키보드일 수도 있다. 복수 버튼의 키보드 (120) 는, 상부 하우징부 (104) 가 하부 하우징부 (106) 에 대해 이동되면 드러날 수도 있다. 도 2는, PCD (100) 가 하부 하우징부 (106) 상에 리셋 버튼 (122) 을 포함할 수도 있음을 또한 나타낸다.

도 3을 참조하면, 예시적이고 비제한적인 양태의 휴대형 컴퓨팅 디바이스 (PCD) 가 도시되는데, 일반적으로 100으로 나타낸다. 도시된 바와 같이, PCD (100) 는 멀티코어 CPU (402) 를 포함하는 온칩 시스템 (322) 을 포함한다. 멀티코어 CPU (402) 는 제 0의 코어 (410), 제 1의 코어 (412), 및 제 N의 코어 (414) 를 포함할 수도 있다.

도 3에 도시된 바와 같이, 디스플레이 컨트롤러 (328) 및 터치 스크린 컨트롤러 (330) 는 멀티코어 CPU (402) 에 연결된다. 또한, 온칩 시스템 (322) 외부의 터치스크린 디스플레이 (108) 가 디스플레이 컨트롤러 (328) 및 터치스크린 컨트롤러 (330) 에 커플링된다.

도 3은 비디오 인코더 (334), 예를 들면 PAL (phase alternating line) 인코더, SECAM (sequential color a memoire) 인코더, 또는 NTSC (national television system(s) committee) 인코더가 멀티코어 CPU (402) 에 커플링된 것을 또한 도시한다. 또한, 비디오 증폭기 (336) 가 비디오 인코더 (334) 와 터치스크린 디스플레이 (108) 에 커플링된다. 또한, 비디오 포트 (338) 가 비디오 증폭기 (336) 에 커플링된다. 도 3에 도시된 바와 같이, USB (universal serial bus) 컨트롤러 (340) 가 멀티코어 CPU (402) 에 커플링된다. 또한, USB 포트 (342) 가 USB 컨트롤러 (340) 에 커플링된다. 메모리 (404) 및 가입자 식별 모듈 (subscriber identity module; SIM) 카드 (346) 가 멀티코어 CPU (402) 에 또한 커플링될 수도 있다. 또한, 도 3에 도시된 바와 같이, 디지털 카메라 (348) 가 멀티코어 CPU (402) 에 커플링될 수도 있다. 예시적인 양태에서, 디지털 카메라 (348) 는 CCD (charge-coupled device) 카메라 또는 CMOS (complementary metal-oxide semiconductor) 카메라이다.

도 3에 추가로 도시된 바와 같이, 스테레오 오디오 코덱 (350) 이 멀티코어 CPU (402) 에 커플링될 수도 있다. 또한, 오디오 증폭기 (352) 가 스테레오 오디오 코덱 (350) 에 커플링될 수도 있다. 예시적인 양태에서, 제 1의 스테레오 스피커 (354) 및 제 2의 스테레오 스피커 (356) 가 오디오 증폭기 (352) 에 커플링된다. 도 3은, 마이크 증폭기 (358) 가 스테레오 오디오 코덱 (350) 에 또한 커플링될 수도 있음을 나타낸다. 또한, 마이크 (360) 는 마이크 증폭기 (358) 에 커플링될 수도 있다. 특별한 양태에서, FM (frequency modulation) 라디오 튜너 (362) 가 스테레오 오디오 코덱 (350) 에 커플링될 수도 있다. 또한, FM 안테나 (364) 가 FM 라디오 튜너 (362) 에 커플링된다. 또한, 스테레오 헤드폰들 (366) 이 스테레오 오디오 코덱 (350) 에 커플링될 수도 있다.

도 3은 RF (radio frequency) 트랜시버 (368) 가 멀티코어 CPU (402) 에 커플링될 수도 있음을 더 나타낸다. RF 스위치 (370) 는 RF 트랜시버 (368) 와 RF 안테나 (372) 에 커플링될 수도 있다. 또한, 도 3에 도시된 바와 같이, 키패드 (374) 가 멀티코어 CPU (402) 에 커플링될 수도 있다. 또한, 마이크를 구비한 모노 헤드셋 (376) 이 멀티코어 CPU (402) 에 커플링될 수도 있다. 또한, 진동기 (vibrator) 디바이스 (378) 가 멀티코어 CPU (402) 에 커플링될 수도 있다. 도 3은, 전원 (power supply; 380) 이 온칩 시스템 (322) 에 커플링될 수도 있음을 나타낸다. 특별한 양태에서, 전원 (380) 은 전력을 필요로 하는 PCD (100) 의 여러 컴포넌트들로 전력을 제공하는 직류 (DC) 전원이다. 또한, 특별한 양태에서, 전원은 AC (교류) 전원에 연결된 AC-DC 변압기로부터 유도되는 DC 전원 또는 재충전 가능한 DC 배터리이다.

또한, 도 3은, 데이터 네트워크, 예를 들면, LAN, PAN (personal area network), 또는 임의의 다른 네트워크에 액세스하기 위해 사용될 수도 있는 네트워크 카드 (388) 를 PCD (100) 가 또한 포함할 수도 있음을 나타낸다. 네트워크 카드 (388) 는 블루투스 네트워크 카드, 와이파이 네트워크 카드, PAN 카드, PeANUT (personal area network ultra-low-power technology) 네트워크 카드, 또는 종래기술에서 공지된 임의의 다른 네트워크 카드일 수도 있다. 또한, 네트워크 카드 (388) 는 칩에 통합될 수도 있고, 즉, 네트워크 카드 (388) 는 칩 내의 풀 솔루션 (full solution) 일 수도 있고, 개별적인 네트워크 카드 (388) 가 아닐 수도 있다.

도 3에 도시된 바와 같이, 터치스크린 디스플레이 (108), 비디오 포트 (338), USB 포트 (342), 카메라 (348), 제 1의 스테레오 스피커 (354), 제 2의 스테레오 스피커 (356), 마이크 (360), FM 안테나 (364), 스테레오 헤드폰들 (366), RF 스위치 (370), RF 안테나 (372), 키패드 (374), 모노 헤드셋 (376), 진동기 (378), 및 전원 (380) 은 온칩 시스템 (322) 의 외부에 있다.

특별한 양태에서, 본 개시에서 설명된 하나 이상의 방법 단계들은 컴퓨터 프로그램 명령들로서 메모리 (404) 에 저장될 수도 있다. 이들 명령들은 본원에서 설명된 방법들을 수행하기 위해 멀티코어 CPU (402) 에 의해 실행될 수도 있다. 또한, 멀티코어 CPU (402), 메모리 (404), 또는 이들의 조합은, CPU (402) 내에서 데이터를 샘플링하기 위해 본원에서 설명된 하나 이상의 방법 단계들을 실행하기 위한 수단으로서 기능할 수도 있다.

도 4를 참조하면, 프로세싱 시스템이 도시되며 일반적으로 400으로 지칭된다. 특별한 양태에서, 프로세싱 시스템 (400) 은 도 3과 연계하여 위에서 설명된 PCD (100) 로 통합될 수도 있다. 도시된 바와 같이, 프로세싱 시스템 (400) 은 멀티코어 CPU (402) 및 멀티코어 CPU (402) 에 연결된 메모리 (404) 를 포함할 수도 있다. 멀티코어 CPU (402) 는 제 0의 코어 (410), 제 1의 코어 (412), 및 제 N의 코어 (414) 를 포함할 수도 있다. 제 0의 코어 (410) 는 그 상에서 실행하는 제 0의 동적 클록 및 전압 스케일링 (dynamic clock and voltage scaling; DCVS) 알고리즘 (416) 을 포함할 수도 있다. 제 1의 코어 (412) 는 그 상에서 실행하는 제 1의 DCVS 알고리즘 (417) 을 포함할 수도 있다. 또한, 제 N의 코어 (414) 는 그 상에서 실행하는 제 N의 DCVS 알고리즘 (418) 을 포함할 수도 있다. 특별한 양태에서, 각각의 DCVS 알고리즘 (416, 417, 418) 은 각각의 코어 (412, 414, 416) 상에서 독립적으로 실행될 수도 있다.

또한, 도시된 바와 같이, 메모리 (404) 는 그 상에 저장된 오퍼레이팅 시스템 (420) 을 포함할 수도 있다. 오퍼레이팅 시스템 (420) 은 버스 아비터 (arbiter) 또는 스케줄러 (422) 를 포함할 수도 있고 스케줄러 (422) 는 제 1의 런 큐 (424), 제 2의 런 큐 (426), 및 제 N의 런 큐 (428) 를 포함할 수도 있다. 메모리 (404) 는 그 상에 저장된 제 1의 어플리케이션 (430), 제 2의 어플리케이션 (432), 및 제 N의 어플리케이션 (434) 을 또한 포함할 수도 있다.

특별한 양태에서, 어플리케이션들 (430, 432, 434) 은, 멀티코어 CPU (402) 내의 코어들 (410, 412, 414) 에서 처리될 하나 이상의 태스크들 (436) 을 오퍼레이팅 시스템 (420) 으로 전송할 수도 있다. 태스크들 (436) 은 단일의 태스크들, 스레드들, 또는 이들의 조합으로서 프로세싱되거나, 또는 실행될 수도 있다. 또한, 스케줄러 (422) 는 멀티코어 CPU (402) 내에서의 실행을 위해 태스크들, 스레드들, 또는 이들의 조합을 스케줄링할 수도 있다. 추가적으로, 스케줄러 (422) 는 태스크들, 스레드들, 또는 이들의 조합을 런 큐들 (424, 426, 428) 내에 배치할 수도 있다. 코어들 (410, 412, 414) 은, 코어들 (410, 412, 414) 에서의 태스크들 및 스레드들의 프로세싱 또는 실행을 위해, 예를 들면 오퍼레이팅 시스템 (420) 에 의해 지시된 바와 같이 런 큐들 (424, 426, 428) 로부터 이들 태스크들, 스레드들, 또는 이들의 조합을 취출할 수도 있다.

도 4는 메모리 (404) 가 그 상에 저장된 프레임워크 매니저 (440) 를 포함할 수도 있다는 것을 또한 나타낸다. 프레임워크 매니저 (440) 는 오퍼레이팅 시스템 (420) 과 멀티코어 CPU (402) 에 연결될 수도 있다. 구체적으로는, 프레임워크 매니저 (440) 는 오퍼레이팅 시스템 (420) 내의 스케줄러 (422) 에 연결될 수도 있다. 본원에서 설명된 바와 같이, 프레임워크 매니저 (440) 는 코어들 (410, 412, 414) 에 대한 작업부하를 모니터링할 수도 있고 프레임워크 매니저 (440) 는 하기에 설명되는 바와 같이 코어들 (410, 412, 414) 로부터 데이터를 샘플링할 수도 있다.

특별한 양태에서, 프레임워크 매니저 (440) 는 소프트웨어 프로그램일 수도 있다. 그러나, 대안적 양태에서, 프레임워크 매니저 (440) 는 메모리 (404) 외부에 있는 하드웨어 컨트롤러일 수도 있다. 어느 경우에서든, 프레임워크 매니저 (440), 메모리 (404), 코어들 (410, 412, 414), 또는 이들의 임의의 조합은, 코어들 (410, 412, 414) 로부터 데이터를 샘플링하기 위해 본원에서 설명된 하나 이상의 방법 단계들을 실행하기 위한 수단으로서 기능할 수도 있다.

도 5는 도 1의 휴대형 컴퓨팅 디바이스 (PCD) 의 리소스들을 관리하는 시스템에 대한 소프트웨어 아키텍쳐 (500A) 의 제 1의 양태의 도면이다. 도 5는 소프트웨어 또는 하드웨어 (또는 양자) 를 나타내는 기능적 블록들을 포함하는 도면이다. 도 5는, 일반적으로 제 1의 하드웨어 엘리먼트 (하드웨어 엘리먼트 #1) 로서 또한 칭해지는 CPU (402) ; 일반적으로 제 2의 하드웨어 엘리먼트 (하드웨어 엘리먼트 #2) 로서 또한 칭해지는 CPU (402) 용 클록 (442) ; 일반적으로 제 3의 하드웨어 엘리먼트 (하드웨어 엘리먼트 #3) 로서 또한 칭해지는 버스 아비터 또는 스케줄러 (422) ; 일반적으로 제 1의 소프트웨어 엘리먼트 (소프트웨어 엘리먼트 #1) 로서 또한 칭해지는 버스 프로그램 A (444A) ; 일반적으로 제 2의 소프트웨어 엘리먼트 (소프트웨어 엘리먼트 #2) 로서 또한 칭해지는 버스 프로그램 B (444B), 일반적으로 제 3의 소프트웨어 엘리먼트 (소프트웨어 엘리먼트 #3) 로서 또한 칭해지는 클록 프로그램 AHB; 키눌림으로서 일반적으로 나타내어지는 소프트웨어 엘리먼트에 의해 모니터링되는 액션 또는 기능 (448) ; 및 소프트웨어 엘리먼트 또는 소프트웨어 엘리먼트 또는 양자를 포함하는 리거시 엘리먼트 (450) 와 같은, 그러나 이들에 제한되지 않는 복수의 하드웨어 및 소프트웨어 엘리먼트들에 커플링된 아키텍쳐 또는 프레임워크 매니저 (440) 를 도시한다.

리거시 소프트웨어 엘리먼트의 실시예는 DEM (Dynamic Environment Manager) 을 포함할 수도 있지만, 이것에 제한되는 것은 아니다. 이것은 프로세서 슬립 이벤트들의 프로세서간 통지 (interprocessor notification) 를 핸들링하는 소프트웨어 모듈이다. 예를 들면, 제 1의 프로세서 A는, 제 2의 프로세서 B가 아이들 상태로 들어갔다는/아이들 상태로부터 복귀했다는 통지를 수신하기 위해 DEM을 사용한다. 더 새로운 하드웨어 상에서, 이 소프트웨어 기능은 RPM (route processor module) 서브시스템/통신 프로토콜로 포함되었다. 다른 리거시 소프트웨어 엘리먼트들이 존재하며 본 발명의 범위 내에 포함된다.

리거시 하드웨어 엘리먼트의 실시예는, AMBA ("Advanced Microcontroller Bus Architecture") 의 고성능 버스 (AMBA High-performance Bus; AHB) 를 포함할 수도 있지만, 이것에 제한되는 것은 아니다. 이전 PCD들 (100) 상에서, AHB는 주 시스템 버스를 포함할 수도 있지만, 반면 새로운 PCD들 (100) 상에서, 시스템 버스 패브릭은 완전히 상이하고 AHB 버스는 새로운 시스템 버스 패브릭을 통해 통신하도록 아직 업데이트되지 않은 모듈들과 통신하기 위해 특별한 어플리케이션들을 위해서만 사용된다. 다른 리거시 하드웨어 엘리먼트들이 존재하며 본 발명의 범위 내에 포함된다.

프레임워크 매니저 (440) 는, 상기 언급된 하드웨어 및 소프트웨어 엘리먼트들의 각각과 통신하는 노드들 (하기에 설명됨) 과 같은 데이터 구조들을 관리하는 컴퓨터 명령들의 라이브러리를 포함할 수도 있다. 프레임워크 매니저 (440) 는 도 5의 점선 A의 우측에 도시된 바와 같은 노드들 (602, 622, 642, 및 646) 을 형성할 수도 있는 하나 이상의 리소스들을 생성할 책임이 있을 수도 있다. 프레임워크 매니저는 코드의 라이브러리를 포함할 수도 있다. 라이브러리의 일부분들은 PCD (100) 의 각각의 하드웨어 엘리먼트 상에 상주할 수도 있다.

한편, 프레임워크 매니저 (440) 에 의해 확립되고 인스턴스화된 각각의 노드 (602, 622, 642, 및 646) 는 도 5의 점선 A의 좌측에 있는 각각의 소프트웨어 또는 하드웨어 엘리먼트의 모델 또는 표현이다. 본 개시의 나머지에 대해, 도 6a에서 도시된 바와 같이, 범용의 또는 비특정적 노드가 도면번호 601로 나타내어질 것이다.

앞서 언급된 바와 같이, 도 5의 각각의 예시적인 노드 (602, 622, 642, 및 646) 는 하나 이상의 리소스들을 포함할 수도 있다. 리소스는 소프트웨어 엘리먼트 또는 하드웨어 엘리먼트 또는 양자를 포함할 수도 있다. 예를 들면, 제 1의 노드 (602) 는 제 1의 하드웨어 엘리먼트 또는 CPU (402) 와 일반적으로 대응하는 단일의 리소스를 포함한다. 본 개시에서 설명된 본 발명의 소프트웨어 아키텍쳐에 의하면, 노드 (601) 의 각각의 리소스는 하나 이상의 영숫자 (alphanumeric) 문자들을 포함하는 고유의 명칭을 구비할 수도 있다. 도 5에 예시된 예시적인 실시형태에서, 제 1의 노드 (602) 의 리소스는 "/core/cpu"의 리소스 명칭을 할당받았다. 이 예시적인 리소스 명칭은, 당업자에게 알려진 종래의 파일 네이밍 구조들에 일반적으로 대응한다. 그러나, 당업자에 의해 인식될 수 있는 바와 같이, 영숫자 문자들 및/또는 심볼들의 임의의 다른 조합을 포함하는 다른 타입들의 리소스 명칭들도 본 발명의 범위 내에 또한 있다.

도 5의 예시적인 실시형태에서, 제 2의 노드 (622) 는 복수의 리소스들을 포함한다. 구체적으로는, 이 특별한 예시적인 실시형태에서, 제 2의 노드 (622) 는 버스 아비터 또는 스케줄러 (422) 에 대응하는 단일의 하드웨어 엘리먼트를 포함하는 제 1의 리소스를 구비한다. 제 2의 노드 (622) 의 제 2의 리소스는 버스 프로그램 A (444A) 의 제 1의 소프트웨어 엘리먼트에 일반적으로 대응하는 소프트웨어 엘리먼트를 포함한다. 제 2의 노드 (622) 의 제 3의 리소스는 버스 프로그램 B (444B) 의 제 2의 소프트웨어 엘리먼트에 일반적으로 대응하는 다른 소프트웨어 엘리먼트를 포함한다. 당업자는, 주어진 노드 (601) 에 대한 임의의 조합 및 임의의 수의 리소스들 및 리소스 타입들이 본 발명의 범위 내에 있다는 것을 잘 알고 있다.

도 5는 2개의 소프트웨어 엘리먼트들 (448, 450) 의 액션 또는 기능에 일반적으로 대응하는 제 1의 클라이언트 (648) 를 또한 도시한다. 도 5에 도시된 예시적인 실시형태에서, 클라이언트 (648) 는, 휴대형 컴퓨팅 디바이스 (100) 에 의해 지지되는 특별한 어플리케이션 프로그램 내에서 발생할 수도 있는 키눌림 액션에 일반적으로 대응한다. 그러나, 당업자는 키눌림들 이외의 소프트웨어 엘리먼트들의 다른 액션들 및/또는 기능들이 본 발명의 범위 내에 있다는 것을 잘 알고 있다. 클라이언트들 (648) 및 그들 각각의 생성에 관한 추가적인 상세들은 도 12와 연계하여 설명될 것이다.

도 5는 특별한 아키텍쳐적인 엘리먼트들 사이의 관계들을 또한 도시한다. 예를 들면, 도 5는 클라이언트 (648) 및 제 1의 노드 (602) 사이의 관계를 도시한다. 구체적으로는, 제 1의 클라이언트 (648) 는 점선들로 도시된 클라이언트 요청들 (675A) 을 생성할 수도 있는데, 이것은 리소스 "/Core/cpu"를 포함하는 제 1의 노드 (602) 에 의해 관리 또는 핸들링된다. 통상적으로, 미리 결정된 또는 설정된 수의 타입들의 클라이언트 요청들 (675) 이 존재한다. 클라이언트 요청들 (675) 은 도 13과 연계하여 하기에 더 상세히 설명될 것이다.

도 5에 도시된 다른 관계들은 점선들 (680) 로 도시된 의존성들을 포함한다. 의존성들은 다른 노드 (601) 의 각각의 리소스들 사이의 관계들이다. 의존성 관계는, 제 1의 리소스 (A) 에게 정보를 제공할 수도 있는 제 2의 리소스 (B) 에 제 1의 리소스 (A) 가 의존한다는 것을 보통 나타낸다. 이 정보는 제 2의 리소스 (B) 에 의해 수행된 동작의 결과일 수도 있거나 또는 제 1의 리소스 (A) 또는 이들의 임의의 조합에 의해 필요한 스테이터스 정보 (status information) 를 단순히 포함할 수도 있다. 제 1의 리소스 (A) 와 제 2의 리소스 (B) 는 동일한 노드 (601) 의 일부일 수도 있거나 또는 상이한 노드들 (601) 의 일부일 수도 있다.

도 5에서, 제 1의 노드 (602) 는, 제 1의 노드 (602) 로부터 발생하고 제 2의 노드 (622) 로 연장하는 의존성 화살표 (680B) 에 의해 나타내어진 바와 같이, 제 2의 노드 (622) 에 의존한다. 도 5는, 제 1의 노드 (602) 가 의존성 화살표 (680A) 에 의해 도시된 바와 같이 제 3의 노드 (642) 에도 또한 의존함을 또한 도시한다. 도 5는, 제 2의 노드 (622) 가 의존성 화살표 (680C) 에 의해 도시된 바와 같이 제 4의 노드 (646) 에 의존함을 또한 도시한다. 도 5의 점선의 화살표들로 도시된 의존성들 (680) 이 사실 단지 예증적인 것이며 각각의 노드들 (601) 사이의 의존성들의 다른 조합들이 본 발명의 범위 내에 있음을 당업자는 알고 있다.

프레임워크 매니저 (440) 의 아키텍쳐는, 도 5에서 도시된 클라이언트 요청들 (675) 및 의존성들 (680) 을 포함하지만 이들에 제한되지 않는, 위에서 설명된 관계들을 유지하는 책임이 있다. 프레임워크 매니저 (440) 는, 임의의 주어진 노드 (601) 에 대한 의존성들 (680) 이 완전한 한, 가능한 한 많은 노드들 (601) 을 인스턴스화하도록 또는 생성하도록 시도할 것이다. 의존성을 지원하는 리소스가 존재하거나 또는 의존성 (680) 에 관련하는 정보를 핸들링하기 위한 준비 상태에 있는 경우, 의존성 (680) 은 완전하다.

예를 들면, 제 1의 노드 (602) 와 제 3의 노드 (642) 사이에 존재하는 의존성 관계 (680A) 때문에, 단일의 리소스 "/clk/cpu"를 포함하는 제 3의 노드 (642) 가 생성되지 못한 경우, 단일의 리소스 "/Core/cpu"를 포함하는 제 1의 노드 (602) 는 프레임워크 매니저 (440) 에 의해 생성되지 않거나 확립되지 않을 수도 있다. 제 3의 노드 (642) 가 프레임워크 매니저 (440) 에 의해 생성되면, 의존성 관계 (680A) 때문에 프레임워크 매니저 (440) 는 제 2의 노드 (602) 를 생성할 수도 있다.

프레임워크 매니저 (440) 가 특별한 노드 (601) 를, 하나 이상의 그것의 의존성들 (680) 이 완전하지 못하기 때문에, 생성하지 못하거나 인스턴스화하지 못하는 경우, 프레임워크 매니저 (440) 는 프레임워크 매니저 (440) 에 의해 성공적으로 생성된 그들 노드들 (601) 에 대응하는 단계들을 작동하거나 실행하는 것을 계속할 것이다. 프레임워크 매니저 (440) 는 의존적 리소스들이 생성되지 않은 불완전한 의존성들로 인해 존재하지 않을 수도 있는 특별한 노드 (601) 에 대한 호를 통상 스킵하고 그 불완전한 스테이터스를 반영하는 메시지들을 그 호로 리턴할 것이다.

도 4에 예시된 것과 같은 멀티코어 환경에서, 프레임워크 매니저 (440) 는, 도 4의 제 1, 제 2 및 제 N의 코어들 (424, 426, 및 428) 과 같은 별개의 코어들 상에 노드들 (601) 을 생성하거나 인스턴스화할 수도 있다. 일반적으로, 노드들 (601) 은, 노드들 (601) 이 서로 의존적이지 않는 한 그리고 모든 특별한 노드의 대응하는 의존성들이, 하기에 설명되는 바와 같이, 완전한 경우, 별개의 코어들 상의 멀티코어 환경에서 그리고 병렬로 생성될 수도 있다

도 6a는 도 1의 PCD (100) 의 리소스들을 관리하는 시스템에 대한 소프트웨어 아키텍쳐 (500B1) 의 제 2의 양태의 일반적인 도면이다. 이 일반적인 도면에서, 각 노드 (601) 의 하나 이상의 리소스들은 고유 명칭들을 제공받지 못했다. 도 6a의 노드 또는 리소스 그래프 (500B1) 는 노드들 (601), 클라이언트들 (648), 이벤트들 (690), 및 아키텍쳐 또는 프레임워크 매니저 (440) 에 의해 지원되는 쿼리 기능들 (695) 만을 포함한다. 각 노드 (601) 는 타원 형상 및 노드 (601) 내에서의 리소스들 사이의 각각의 의존성들을 나타내는 특정 방향들을 갖는 화살표들 (680) 로 도시된다.

도 6a 및 도 6b에 도시된 노드 아키텍쳐 내에서의 호들은 앨리어스에 대해, 또는 노드 (601) 내의 리소스의 실제 리소스 명칭에 대해 행해질 수도 있다. 예를 들면, 제 1의 노드 (601A) 는, 제 1의 노드 (601A) 가 제 2의 노드 (601B) 의 2개의 리소스들 (리소스들 #2 및 #3) 에 의존함을 나타내는 의존성 화살표 (680A) 를 갖는다. 도 6a는, 제 1의 노드 (601A) 의 클라이언트 (648) 가 제 1의 노드 (601A) 에 대해 클라이언트 요청 (675) 을 어떻게 발행할 수도 있는지를 또한 도시한다. 이들 클라이언트 요청들 (675) 이 발행되면, 제 2의 노드 (601B) 는 이벤트 (690) 를 트리거하거나 또는 쿼리 (695) 에 대한 응답을 제공하는데, 여기에서 쿼리 (695) 및 이벤트 (690) 에 대응하는 메시지들은 다시 클라이언트 (648) 로 흐르게 된다.

도 6b는 도 1의 PCD (100) 의 리소스들을 관리하는 시스템에 대한 소프트웨어 아키텍쳐 (500B2) 의 제 2의 양태의 특정 도면이다. 도 6b는, 도 5의 것들에 대응하는 쿼리 기능들 (695), 이벤트들 (690), 및 클라이언트들 (648) 뿐만 아니라, 특정하지만 여전히 예시적인 리소스 명칭들을 갖는 노드들 (601) 만을 포함하는 노드 또는 리소스 그래프 (500B2) 를 도시한다. 각 노드 (601) 는 타원 형상 및 노드 (601) 내에서의 리소스들 사이의 각각의 의존성들을 나타내는 특정 방향들을 갖는 화살표들 (680) 로 도시된다.

예를 들면, 제 1의 노드 (602) 는, 제 1의 노드 (602) 가 제 2의 노드 (622) 의 3개의 리소스들에 의존함을 나타내는 의존성 화살표 (680B) 를 갖는다. 마찬가지로, 제 2의 소프트웨어 엘리먼트 (444B) 를 포함하며 도 6에서 도면부호 "C"로 일반적으로 지정된 제 3의 리소스 "/bus/ahb/sysB"는, 이 제 3의 리소스 (C) 가 제 4의 노드 (646) 의 단일의 "/clk/sys/ahb" 리소스에 의존한다는 것을 나타내는 의존성 화살표 (680C) 를 갖는다.

도 6b는 하나 이상의 이벤트들 (690) 또는 쿼리 기능들 (695) 을 포함할 수도 있는 노드들 (601) 로부터의 출력 데이터를 또한 도시한다. 쿼리 기능 (695) 은 이벤트 (690) 와 유사하다. 쿼리 기능 (695) 은 고유하거나 고유하지 않을 수도 있는 쿼리 핸들을 구비할 수도 있다.

쿼리 기능은 일반적으로 외부에서 식별되지 않고 따라서 일반적으로 상태를 갖지 않는다. 쿼리 기능 (695) 은 노드 (601) 의 특별한 리소스의 상태를 결정하기 위해 사용될 수도 있다. 쿼리 기능 (695) 및 이벤트들 (690) 은 확립된 클라이언트들 (648) 과 관계를 가질 수도 있고, 이들 관계들은, 각각의 이벤트 (690) 및 쿼리 기능 (695) 으로부터의 정보가 특별한 클라이언트 (648) 로 전달됨을 나타내는 방향성 화살표들 (697) 에 의해 표현될 수도 있다.

도 6의 노드 또는 리소스 그래프들 (500B) 은, 메모리, 예컨대 도 4의 메모리 (404) 에 존재하는 관계를 나타내며, 이들은 노드들 (601) 을 포함할 수도 있는 관련 데이터 구조들 및 프레임워크 매니저 (440) 에 의해 관리된다. 노드 또는 리소스 그래프 (500B) 는, 소프트웨어 팀에 의한 문제해결을 위한 그리고 프레임워크 매니저 (440) 에 의해 관리되는 각각의 엘리먼트들 사이의 관계를 식별하기 위한 유용한 툴로서 프레임워크 매니저 (440) 에 의해 자동적으로 생성될 수 있다.

도 6c는 소프트웨어 아키텍쳐 (500) 의 리소스들에 대해 추적될 수도 있는 예시적인 온도 임계치 이벤트들 (690) 을 도시하는 도면이다. 도 6c에 도시된 임계치 이벤트들 (690) 이 온도에 관련되지만, 임계치 이벤트들은 PCD (100) 내에서 모니터링될 수도 있는 임의의 타입의 조건과 관련될 수도 있다는 것을 당업자는 알고 있다. 예를 들면, 다른 임계치 이벤트들은, 소비 전력, 배터리 충전 스테이터스/상태, 슬립 또는 저전력 조건들, 양호한, 보통의, 불량의 RF (radio-frequency) 수신과 같은 특정 하드웨어 조건들, MIPs (millions of instructions per second) 와 같은 부하들에 관련될 수도 있는 동작 조건들, 클록 주파수, 버스 주파수, 전압, DCVS 상태들 및 알고리즘 등을 포함하지만, 이들에 제한되는 것은 아니다.

임계치 이벤트들 (690) 은 보통 하나 이상의 트리거링 조건들을 포함한다. 도 6c에 도시된 실시예에서, 트리거링 조건들은 PCD (100) 로 측정될 수도 있는 하나 이상의 온도들을 포함할 수도 있다. 도 6c의 실시예에서, 3개의 임계치 온도들이 선택되었다: A) PCD (100) 에 대한 고열 상태를 나타낼 수도 있는 섭씨 80도씨; B) PCD (100) 에 대한 공칭 열 상태 (nominal thermal state) 를 나타낼 수도 있는 섭씨 65도씨; 및 C) PCD (100) 에 대한 저열 상태를 나타낼 수도 있는 섭씨 50도씨.

온도가 섭씨 50도씨 이하인 경우의 열 조건을 추적하도록 제 1의 임계치 이벤트 (690A) 가 생성되었다. 온도가 섭씨 50도씨 이하이거나 섭씨 80도씨 이상인 경우의 열 조건을 추적하도록 제 2의 임계치 이벤트 (690B) 가 생성되었다. 온도가 섭씨 65도씨 이하인 경우의 열 조건을 추적하도록 제 3의 임계치 이벤트 (690C) 가 생성되었다. 온도가 섭씨 50도씨 이하이거나, 또는 섭씨 65도씨에 도달했거나, 또는 섭씨 80도씨에 도달한 경우의 열 조건을 추적하도록 제 4의 임계치 이벤트 (690D) 가 생성되었다.

도 6d와 연계하여 하기에 더 상세히 설명되는 것처럼, PCD (100) 의 동일한 리소스들, 상이한 리소스들, 또는 리소스들의 여러 조합들에 대해, 이들 4개의 상이한 임계치 이벤트들 (690A, 690B, 690C, 690D) 의 각각이 할당될 수도 있다. 프레임워크 매니저 (440) 에 의해 지원되는 소프트웨어 아키텍쳐 (500) 의 임의의 유저는 리소스에 대해 임계치 이벤트 (690) 를 셋업할 수도 있다. 임계치 이벤트들 (690) 을 생성하는 소프트웨어 아키텍쳐 (500) 의 유저는 리소스 오써 (resource author), 노드 오써, 리소스, 또는 실행 스레드 (thread of execution) 를 포함할 수도 있다. 임계치 이벤트 (690) 에 할당된 리소스들은 하나 이상의 상이한 리소스들로 임계치 이벤트의 스테이터스를 보고하도록 지시될 수도 있다.

도 6d는 리소스들 및 각각의 리소스에 의해 추적될 수도 있는 대응하는 예시적인 온도 임계치 이벤트들 (690) 의 차트 (697) 를 도시하는 도면이다. 도 6d의 이들 온도 임계치 이벤트들 (690) 은 도 6c의 온도 임계치 이벤트들 (690) 에 대응한다. 이 예시적인 실시형태에 따르면, 차트 (697) 의 제 1의 칼럼은 제 2의 칼럼에 열거된 임계치 이벤트들을 추적할 책임이 있는 각각의 리소스를 열거한다. 제 3의 칼럼은, 임계치들이 도달되는 경우 임계치 이벤트들의 스테이터스를 수신할 리소스 수신측들을 열거한다.

도 6a의 제 1의 리소스 (리소스 #1) 에는 2개의 온도 임계치 이벤트들 (도 6c의 제 1의 온도 임계치 이벤트 (690A) 및 제 2의 온도 임계치 이벤트 (690B)) 이 할당되었다. 제 1의 리소스는 자신의 임계치 스테이터스를 단일의 리소스 (제 4의 리소스) 로 송신할 것이다. 도 6a의 제 2의 리소스 (리소스 #2) 에는 2개의 온도 임계치 이벤트들 (도 6c의 제 1의 온도 임계치 이벤트 (690A) 및 제 3의 온도 임계치 이벤트 (690C)) 이 할당되었다. 제 2의 리소스는 자신의 임계치 스테이터스를 단일의 리소스 (제 5의 리소스) 로 보고할 것이다. 도 6a의 제 3의 리소스 (리소스 #3) 에는 단일의 온도 임계치 이벤트 (도 6c의 제 4의 온도 임계치 이벤트 (690D)) 가 할당되었다. 제 3의 리소스는 자신의 임계치 스테이터스를 2개의 리소스 (제 4의 리소스 및 제 6의 리소스) 로 보고할 것이다.

도 6d의 차트 (697) 는, 임계치 이벤트들 (690) 이 어떻게 리소스들에 할당될 수도 있고 이들 이벤트들 (690) 이 어떻게 보고될 수도 있는지의 유연성 및 확장성 (scalability) 을 도시한다. 프레임워크 매니저 (440) 는 차트 (697) 에 열거된 리소스들 사이의 통신들을 모니터링하고 지원할 책임이 있다. 임계치 이벤트들 (690) 을 생성하기 위한 방법 또는 프로세스 (1600) 는 도 16과 연계하여 하기에 설명될 것이다. 임계치 이벤트들 (690) 을 생성하기 위한 방법 (1600) 은, 소프트웨어 아키텍쳐 (500) 을 생성하기 위한 그리고 PCD의 리소스(들) 를 관리하기 위한 방법 (700A) 이 실행된 이후 실행될 수도 있다.

도 7a는 PCD (100) 의 리소스(들) 를 관리하기 위한 소프트웨어 아키텍쳐를 생성하는 방법 (700A) 을 도시하는 흐름도이다. 블록 (705) 은 PCD (100) 의 리소스들을 관리하기 위한 방법 또는 프로세스 (700) 의 제 1의 루틴이다. 블록 (705) 에서, 루틴은 노드 구조 데이터를 수신하기 위한 프레임워크 매니저 (440) 에 의해 실행되거나 작동될 수도 있다. 노드 구조 데이터는, 특별한 노드 (601) 가 다른 노드들 (601) 과 가질 수도 있는 의존성들을 나타내는 의존성 화살표를 포함할 수도 있다. 노드 구조 데이터 및 이 루틴 또는 서브 방법 (705) 에 관한 추가적인 상세들은 도 8과 연계하여 하기에 더 상세히 설명될 것이다.

다음에, 블록 (710) 에서, 프레임워크 매니저 (440) 는 블록 (705) 에서 수신된 노드 구조 데이터의 일부인 의존성 데이터를 리뷰할 수도 있다. 결정 블록 (715) 에서, 프레임워크 매니저 (440) 는, 노드 구조 데이터가 리프 노드 (601) 를 정의하는지 아닌지를 결정할 수도 있다. 일반적으로, 리프 노드 (601) 는, 노드 구조 데이터에 기초하여 생성될 노드가 어떠한 의존성들도 갖지 않음을 의미한다. 결정 블록 (715) 에 대한 질의가 긍정적이면, 즉, 현재의 노드를 생성하는 노드 구조 데이터가 어떠한 의존성들도 갖지 않으면, 프레임워크 매니저 (440) 는 루틴 블록 (725) 으로 진행한다.

결정 블록 (715) 에 대한 질의가 부정적이면, "아니오" 분기에 결정 블록 (720) 이 후속하는데, 여기에서, 프레임워크 매니저는 노드 구조 데이터 내의 모든 경성 의존성들 (hard dependencies) 이 존재하는지 아닌지를 결정한다. 경성 의존성은, 리소스가 존재하는 데 필수적인 것을 포함할 수도 있다. 한편, 연성 의존성 (soft dependency) 은, 리소스가 옵션적 단계로서 의존적 리소스를 사용할 수도 있는 것을 포함할 수도 있다. 연성 의존성은, 연성 의존성을 갖는 노드 (601) 의 리소스 또는 노드 (601) 가, 연성 의존성이 존재하지 않는 경우에도 노드 아키텍쳐 내부에서 생성되거나 또는 인스턴스화될 수도 있음을 의미한다.

연성 의존성의 예는, 다수의 리소스들을 포함하는 리소스 지향 노드 (601) 에 대한 동작에 중요하지 않은 최적의 피쳐를 포함할 수도 있다. 프레임워크 매니저 (440) 는, 존재하고 있는 모든 경성 의존성에 대한 노드 또는 리소스를, 생성되지 않은 연성 의존성들을 갖는 이들 노드들 또는 리소스들에 대한 연성 의존성이 존재하지 않는 경우에도 생성하거나 인스턴스화할 수도 있다. 연성 의존성을 참조하기 위해 콜백 피쳐가 사용될 수도 있는데, 그 결과 연성 의존성이 프레임워크 매니저 (440) 에게 이용가능하게 되는 경우, 연성 의존성을 참조하는 각각의 콜백에 대해, 연성 의존성들이 이제 이용가능함을 프레임워크 매니저 (440) 가 통지할 것이다.

결정 블록 (720) 에 대한 질의가 부정적인 경우, "아니오" 분기에 블록 (731) 이 후속하는데, 여기에서, 노드 구조 데이터는 프레임워크 매니저 (440) 에 의해 메모리와 같은 임시 스토리지에 저장된다. 프레임워크 매니저 (440) 는 이 인스턴스화되지 않은 노드와 관련된 콜백 피쳐를 생성한다. 블록 (731) 이전에 그리고 결정 블록 (720) 에 대한 부정적인 조건 또는 긍정적인 조건 중 어느 하나 이후에, 이용불가능하게 된 인스턴스화되지 않은 노드들 (601) 을 관리하기 위한 옵션적 방법 (700C) 이 실행될 수도 있다. 이 옵션적 방법 (700C) 은 도 7a에서 블록 (720) 과 블록 (731) 사이의 점선들로 도시되어 있다. 옵션적 방법 (700C) 의 추가적인 상세들은 도 7c와 연계하여 하기에 설명될 것이다.

결정 블록 (715) 에 대한 질의가 긍정적이면, "예" 분기에 루틴 (725) 이 후속하는데, 여기에서는, 루틴 블록 (705) 에서 수신된 노드 구조 데이터에 기초하여 노드 (601) 가 생성되거나 또는 인스턴스화된다. 루틴 블록 (725) 의 추가적 상세들은 도 9와 연계하여 하기에 설명될 것이다. 다음에, 블록 (732) 에서, 프레임워크 매니저 (440) 는 새롭게 생성된 노드 (601) 를 그것의 고유한 리소스 명칭(들) 을 사용하여 공표하여, 그 결과 다른 노드들 (601) 은 새롭게 생성된 노드 (601) 로 정보를 전송하거나 새롭게 생성된 노드 (601) 로부터 정보를 수신할 수도 있게 된다.

이제, 도 7a의 계속 흐름도인 도 7b를 참조하면, 블록 (735) 에서, 프레임워크 매니저 (440) 는, 새롭게 생성된 노드 (601) 에 의존하는 다른 노드들 (601) 에 대해, 새롭게 생성된 노드 (601) 가 인스턴스화되었고 정보를 수신하거나 송신할 준비가 되어 있다는 것을 통지한다.

일 예시적인 양태에 따르면, 도 6a의 노드 (601B) 와 같은 의존적 노드가 생성되자마자 통지들이 트리거된다, 즉 통지들은 재귀적으로 수행된다. 도 6a의 노드 (601B) 가 구성되면, 노드 (601A) 는 즉시 통지받는다. 이 통지는, (노드 (601B) 가 노드 (601A) 의 최종 의존처였기 때문에) 노드 (601A) 가 구성되는 것을 허용할 수도 있다. 노드 (601B) 의 구성으로 인해, 다른 노드들 (601) 이 계속 통지받을 수도 있다. 노드 (601B) 에 의존하는 최종 리소스가 완료될 때까지 노드 (601B) 는 완성되지 않는다.

제 2의, 약간 더 복잡한, 구현예는, 모든 통지들을 별개의 통지 큐에 둘 것이고, 그 다음 시간의 단일 지점에서 큐를 통해 작동할 것이다, 즉, 통지들은 반복적으로 수행된다. 따라서 도 6a의 노드 (601B) 가 구성되면, 노드 (601A) 로의 통지가 리스트 상으로 푸시된다. 그 다음, 그 리스트는 실행되고 노드 (601A) 는 통지받게 된다. 이것은, (노드 (601A) 외에, 도 6a에 도시되지 않은) 다른 추가적인 노드들 (601) 로의 통지가 동일한 리스트 상에 놓이게 하고, 그 다음, 그 통지는 노드 (601A) 로의 통지가 전송된 후 전송된다. (노드 (601A) 로의 통지 외에) 다른 노드들 (601) 로의 통지들은, 노드 (601B) 및 노드 (601A) 와 관련된 모든 작업이 완료된 이후까지 발생하지 않는다.

논리적으로, 이들 2개의 구현예들은 정확하게 등가적이지만, 그러나, 이들은 구현시 상이한 메모리 소비 특성들을 갖는다. 재귀적 실현은 단순하지만 그러나 임의의 양의 스택 공간을 소비할 수 있고, 스택 소비는 의존성 그래프의 깊이의 함수이다. 반복적 구현은 약간 더 복잡하고 스태틱 메모리 (통지 리스트) 를 약간 더 필요로 하지만, 도 6a에 도시된 바와같이, 스택 사용량은 의존성 그래프의 깊이와 무관하게 일정하다.

또한, 블록 (735) 에서의 노드 생성의 통지는 다른 노드들로 제한되지 않는다. 그것은 앨리어스 구성에 대해 내부적으로 또한 사용될 수도 있다. 단지 다른 노드들이 아니라, 노드 (또는 마커) 가 이용가능하게 되는 경우, 통지를 요청하기 위해 시스템 (500) 에서의 어떤 임의의 엘리먼트는 동일한 메커니즘을 사용할 수 있다. 노드들 및 비노드들 양자는 동일한 통지 메커니즘을 사용할 수도 있다.

결정 블록 (740) 에서, 프레임워크 매니저 (440) 는, 현재 노드 (601) 의 생성에 기초한 인스턴스화 또는 생성에 대해 다른 노드들 (601) 또는 연성 의존성들이 이제 해제 (release) 되는지 아닌지를 결정한다. 생성 또는 인스턴스화를 최근 겪은 현재의 노드에 의해 어떤 의존성 관계들 (680) 이 수행되었기 때문에, 결정 블록 (740) 은 리소스들이 이제 생성될 수도 있는지 아닌지를 일반적으로 결정하고 있다.

결정 블록 (740) 에 대한 질의가 긍정적이면, "예" 분기에 루틴 블록 (725) 이 후속하고, 여기서는, 방금 생성된 노드 (601) 에 의한 의존성의 수행때문에, 해제된 노드 (601) 는 이제 생성되거나 인스턴스화될 수도 있다.

결정 블록 (740) 에 대한 질의가 부정적이면, "아니오" 분기에 블록 (741) 이 후속하고, 여기서는, 프레임워크 매니저 (440) 는, 도 5 및 도 6에 도시된 바와 같이 소프트웨어 아키텍쳐의 엘리먼트들 사이의 통신들을 관리할 수도 있다. 블록 (741) 및 블록 (753) 사이에서, 억제가능한 요청들을 관리하기 위한 옵션적 방법 (700D) 이 프레임워크 매니저 (440) 및 리소스에 의해 실행될 수도 있다. 옵션적 방법 (700D) 의 추가적인 상세들은 도 7d와 연계하여 하기에 설명될 것이다.

다음에, 블록 (753) 에서 그리고 옵션적 방법 (700D) 이후에, 프레임워크 매니저 (440) 는 특별한 리소스와 관련된 리소스 명칭들을 사용함으로써 리소스들에 의해 취해진 액션들을 로깅하거나 기록하는 것을 계속할 수도 있다. 블록 (753) 은, 리소스들, 노드들 (601), 클라이언트들 (648), 이벤트들 (695), 및 쿼리 기능들 (697) 과 같은, 프레임워크 매니저 (440) 에 의해 관리되는 임의의 엘리먼트들 또는 프레임워크 매니저 (440) 에 의해 취해진 임의의 액션 이후에 프레임워크 매니저 (440) 에 의해 실행될 수도 있다. 블록 (753) 은 여전히 본 발명의 한 중요한 양태인데, 여기서는, 프레임워크 매니저 (440) 는, 노드 (601) 의 리소스와 같은, 특별한 엘리먼트를 생성한 오써들에 의해 제공된 그들 고유의 식별자 또는 이름에 따라 각각의 엘리먼트에 의해 수행된 액션들을 열거하는 액티비티의 작동 중인 로그 (running log) 를 유지할 수도 있다.

종래 기술과 비교하여, 시스템의 각각의 리소스에 할당된 고유의 명칭들을 열거하는 블록 (753) 에서의 액티비티의 이 로깅은 고유하며 디버깅 및 에러 문제해결에서 사용되는 것과 같이 상당한 이점들을 제공할 수도 있다. 많은 것 중, 시스템 (500) 을 고유하게 만드는 다른 양태는, 별개의 팀들이 서로 독립적으로 상이한 하드웨어 및/또는 소프트웨어 엘리먼트들 상에서 작업할 수도 있다는 것인데, 여기서 각 팀은, 다른 팀들 및/또는 원래의 OEM들에 의해 할당된 의미가 별로 없고 보통 혼란스러운 리소스 명칭들을 번역하기 위한 테이블들을 생성할 필요 없이, 고유하고 추적이 용이한 리소스 이름들을 사용할 수 있을 것이다.

다음에, 결정 블록 (755) 에서, 프레임워크 매니저 (440) 는, 프레임워크 매니저 (440) 에 의해 기록된 액티비티의 로그가 요청되었는지 아닌지를 결정한다. 결정 블록 (755) 에 대한 질의가 부정적으면, "아니오" 분기에 프로세서의 끝이 후속하며, 여기에서, 루틴 (705) 으로 리턴된다. 결정 블록 (755) 에 대한 질의가 긍정적이면, "예" 분기에 블록 (760) 이 후속하는데, 여기에서, 프레임워크 매니저 (440) 는 의미있는 리소스 명칭들 및 리소스 명칭들에 의해 수행된 각각의 액션들을 포함하는 액티비티 로그를, 프린터 또는 디스플레이 스크린 및/또는 이들 양자와 같은 출력 디바이스로 전송한다. 블록 (760) 이후에, 이용불가능하게 된 인스턴스화된 노드들 (601) 을 관리하기 위한 옵션적 방법 (700E) 이 실행될 수도 있다. 방법 (700E) 의 추가적인 상세들은 도 7d와 연계하여 하기에 설명될 것이다. 블록 (760) 이후에, 프로세스 (700B) 는 위에서 설명된 루틴 블록 (705) 으로 리턴될 수도 있다.

도 7c는 PCD (100) 에 대해 이용불가능하게 된 인스턴스화되지 않은 노드들 (601) 을 관리하기 위한 옵션적 방법 (700C) 을 도시하는 도 7a의 계속 흐름도이다. 노드 (601) 의 리소스가 오프라인으로 취해지거나 장애 조건을 경험하게 된 경우 노드 (601) 는 이용불가능다고 특징지어질 수도 있다. 하나의 예시적인 양태에 따르면, 리소스가 디바이스의 USB 포트 타입과 같이 PCD (100) 로부터 제거될 수도 있는 하드웨어인 경우 리소스는 이용불가능하게 될 수도 있다. 하드웨어 리소스의 드라이버는 도 5의 프레임워크 매니저 (440) 에게, 언제 하드웨어 리소스가 PCD (100) 로부터 제거되었고 프레임워크 매니저 (440) 에 의해 관리될 수도 있는 임의의 요청들을 프로세싱하는 데 하드웨어 리소스가 언제 이용불가능하다는 것을 통지할 수도 있다.

이 옵션적 방법 (700C) 은, PCD (100) 에 커플링될 수도 있는 접속가능한/접속해제 가능한 타입의 리소스들에 아주 적합할 수도 있다. 이 옵션적 방법 (700C) 은, 또한, 도 7a의 루틴 블록 (725) 에서 인스턴스화되지 않거나 생성되지 않은 노드들 (601) 에 맞게 만들어진다. 다시 말하면, 옵션적 방법 (700C) 은 프레임워크 매니저 (440) 에 의해 생성되지 않은 노드들 (601) 에 대한 노드 구조 데이터를 관리하는데, 여기에서 이러한 생성/인스턴스화는 도 7a의 루틴 블록 (725) 에서 보통 발생한다. 옵션적 방법 (700C) 은, 노드에 대응하는 리소스들이 시스템 (500) 으로부터 분리되거나 또는 그 리소스들이 하나 이상의 장애 조건들을 경험하고 있기 때문에 그 리소스들이 이용불가능한 경우, 노드들 (601) 이 생성되는 것을 방지한다.

결정 블록 (721) 은 옵션적 방법 (700C) 의 제 1의 단계이다. 이 결정 블록 (721) 에서, 도 5의 프레임워크 매니저 (440) 는, 시스템 (500) 에 이용가능한 접속가능한 리소스들에 대한 디바이스 드라이버들로부터 프레임워크 매니저가 수신할 수도 있는 메시지들을 모니터링하고 있을 수도 있다. 이전에 언급된 바와 같이, 시스템 (500) 에 이용가능한 접속가능한 리소스들을 관리하는 것에 추가하여, 옵션적 방법 (700C) 은, 장애 조건을 경험한 이들 리소스들을 또한 관리할 수도 있고 이것은 프레임워크 매니저 (440) 에 의해 시스템으로 전송되는 임의의 요청들을 떠맡거나 그 요청들에 대해 작용하는 것을 방지한다. 리소스의 디바이스 드라이버는, 결정 블록 (721) 에서, 프레임워크 매니저 (440) 에게, 프레임워크 매니저 (442) 가 리소스와 그것의 대응하는 노드 (601) 를 오프라인으로 취하는 것을 요구하는 장애 조건을 노드 (601) 의 특별한 리소스가 경험했는지 아닌지를 통지할 수도 있다.

결정 블록 (721) 에 대한 질의가 부정적이면, "아니오" 분기에 블록 (722) 이 후속하는데, 여기에서, 프로세스는 ("아니오" 분기가 결정 블록 (720) 으로부터 후속되면) 도 7a의 블록 (731) 으로 리턴하거나 또는 프로세스는 ("예" 분기가 결정 블록 (720) 으로부터 후속되면) 루틴 블록 (725) 으로 리턴한다. 도 7c의 결정 블록 (721) 에 대한 질의가 긍정적이면, "예" 분기에 블록 (723) 이 후속한다.

블록 (723) 에서, 프레임워크 매니저 (440) 는 하나 이상의 다른 리소스(들) 에 의한 액세스로부터 인스턴스화되지 않은 노드 (601) 를 의존적 노드 (601) 로서 락한다. 다시 말하면, 프레임워크 매니저 (440) 는, 스레드들, 클라이언트들 (648) 등에 의해 발행된 요청들을 프로세싱하는 시스템 (500) 에 인스턴스화되지 않은 노드 (601) 의 하나 이상의 리소스들이 이용불가능한 경우, 다른 노드들 (601) 이 인스턴스화되지 않은 노드 (601) 를 참조하는 것을 방지한다.

블록 (724) 에서, 프레임워크 매니저 (440) 는 인스턴스화되지 않은 노드 (601) 를 디스에이블하여 프레임워크 매니저 (440) 에 의한 그 노드의 늦은 인스턴스화 또는 생성을 방지한다. 다시 말하면, 이 블록 (724) 에서, 프레임워크 매니저 (440) 는, 인스턴스화되지 않은 노드 (601) 를 형성하는 리소스들이 시스템 (500) 으로부터의 요청을 추적할 수 있게 될 때까지, 인스턴스화되지 않은 노드 (601) 가 도 6a의 프레임워크 또는 리소스 그래프 (500B1) 의 일부가 되는 것을 방지하는 프레임워크 매니저 (440) 에 의해 추적되는 플래그 또는 값을 설정할 수도 있다.

결정 블록 (726) 에서, 프레임워크 매니저 (440) 는, 이용불가능한 하나 이상의 리소스들이 시스템 (500) 에 이용가능하게 되도록 상태를 변경했는지 아닌지를 결정하기 위해, 인스턴스화되지 않은 노드 (601) 에 대한 리소스들의 하나 이상의 디바이스 드라이버들로 점검한다. 결정 블록 (726) 에 대한 질의가 부정적이면, "아니오" 분기에 블록 (730) 이 후속하는데, 여기에서, 프로세스 (700) 는 도 7a의 블록 (731) 으로 리턴한다.

결정 블록 (726) 에 대한 질의가 긍정적이면, "예" 분기에 블록 (727) 이 후속하는데, 여기에서, 프레임워크 매니저 (440) 는 인스턴스화되지 않은 노드 (601) 를 인에이블시키고, 그 결과, 도 7a의 루틴 (725) 이 시작되면 인스턴스화되지 않은 노드 (601) 는 인스턴스화되거나 생성될 수 있다. 이 블록 (727) 에서, 프레임워크 매니저 (440) 는 인스턴스화되지 않은 노드 (601) 와 관련된 플래그를 클리어하거나 또는 리셋할 수도 있으며, 그 결과 인스턴스화되지 않은 노드 (601) 는 도 7a의 인스턴스화 루틴 (725) 동안 프레임워크 매니저 (440) 에 의해 프로세싱될 수도 있다.

결정 블록 (728) 에서, 프레임워크 매니저 (440) 는 재인에이블된 여전히 인스턴스화되지 않은 노드 (601) 의 의존성들이 또한 인에이블되는지 아닌지를 결정할 수도 있다. 이 결정 블록 (728) 은, 재인에이블된 여전히 인스턴스화되지 않은 노드 (601) 가 의존할 수도 있는 노드들 (601) 의 리소스들 또는 노드들 (601) 자신이 인에이블된 것을 프레임 매니저 (442) 가 확인하는 것을 허용한다. 결정 블록 (728) 에 대한 질의가 부정적이면, "아니오" 분기에 블록 (730) 이 후속하는데, 여기에서, 프로세스 (700) 는 ("아니오" 분기가 결정 블록 (720) 으로부터 결정 블록 (721) 으로 후속되면) 도 7a의 블록 (731) 으로 리턴하거나 또는 프로세스는 ("예" 분기가 결정 블록 (720) 으로부터 결정 블록 (721) 으로 후속되면) 루틴 블록 (725) 으로 리턴한다.

도 7c의 결정 블록 (728) 에 대한 질의가 긍정적이면, "예" 분기에 블록 (729) 이 후속하는데, 여기에서, 재인에이블된 인스턴스화되지 않은 노드 (601) 는 프레임워크 매니저 (440) 에 의해 언락된다. 재인에이블된 인스턴스화되지 않은 노드 (601) 는, 도 7a의 인스턴스화 루틴 (725) 의 실행 이후 도 6a의 리소스 그래프 (500B1) 가 생성되는 경우 다른 리소스들에 의한 액세스를 위해 언락된다. 그 다음, 옵션적 방법 (700C) 은 ("아니오" 분기가 결정 블록 (720) 에서 결정 블록 (721) 으로 후속되면) 블록 (731) 으로 리턴하거나 또는 프로세스는 ("예" 분기가 결정 블록 (720) 에서 결정 블록 (721) 으로 후속되면) 루틴 블록 (725) 로 리턴한다.

도 7d는 클라이언트, 리소스, 및/또는 스레드 등에 의해 발행된 억제가능한 요청들을 관리하기 위한 옵션적 방법 (700D) 을 도시하는 도 7a의 계속 흐름도이다. 억제가능한 요청들은, 특별한 리소스에 대한 조건 또는 임계치가 충족되면 리소스가 무시하거나 보류할 수도 있는 요청들이다. 임계치 또는 조건은 각각의 리소스에 대해 확립될 수도 있고 각각의 리소스에 대해 고유할 수도 있다. 예시적인 임계치들 또는 조건들은, 슬립 상태들, 고열 조건들, 낮은 배터리 조건들, 및 불량한 무선 수신 등을 포함할 수도 있지만, 이들에 제한되는 것은 아니다. 억제가능한 요청들은, 도 13과 연계하여 하기에 설명되는 바와 같이, 방법 (1300A) 동안, 예컨대 단계 1305에서 생성시에 그렇게 보통 식별된다.

억제가능한 요청들은 요청의 생성 동안 클라이언트에 의해 설정된 플래그 또는 변수를 사용하여 식별될 수도 있다. 리소스는 자신의 요청들을 관리함에 있어서 억제가능한 요청들 피쳐를 이용할 것을 선택하거나 또는 요청이 억제가능한 것인지 또는 아닌지를 무시하는 것을 선택할 수도 있다.

주어진 시나리오 하에서 요청을 보류하거나 연기하는 것이 PCD (100) 에 대해 결과적으로 더 큰 효율성으로 나타날 수도 있다고 리소스가 결정하는 경우, 억제가능한 요청들은 리소스들에 대해 유익하다. 예를 들면, 리소스가 버스를 관리하는 책임이 있다고 가정한다. 리소스는, 버스에 커플링된 CPU가 아이들 상태에 들어가기를 원하는 경우의 조건들을 또한 학습할 수도 있다.

리소스는 버스에 의해 지원되고 있는 대역폭 증가 요청을 수신할 수도 있다. 한편, CPU가 아이들 상태에 막 들어가려고 한다는 메시지를 방금 수신했을 수도 있다. 대역폭에서의 증가에 대한 버스 요청이 억제가능한 요청이다는 지식을 리소스가 가지고 있다면, CPU가 그 아이들 상태를 빠져나올 때까지 리소스는 버스 요청을 또한 억제할 수도 있다. CPU가 아이들 상태에 있는 동안 리소스가 버스 요청을 억제하도록 버스를 관리하는 능력은, PCD (100) 가 전력을 절감하는 데 상당한 효율성을 제공한다. 억제가능한 요청들을 통해 리소스들을 관리하는 효율성을 증가시키기 위한 다른 예시적인 시나리오들은, 본 예의 관점에서 당업자에 의해 쉽게 이해된다.

결정 블록 (742) 은 억제가능한 요청들을 관리하기 위한 방법 (700D) 의 제 1의 단계이다. 결정 블록 (742) 에서, 노드 (601) 의 리소스는, 노드 (601) 의 리소스가 현재 하나 이상의 억제된 요청들을 핸들링하고 있는지 아닌지를 결정할 수도 있다. 결정 블록 (742) 에 대한 질의가 부정적이면, "아니오" 분기에 결정 블록 (745) 이 후속한다.

결정 블록 (742) 에 대한 질의가 긍정적이면, "예" 분기에 결정 블록 (743) 이 후속한다. 결정 블록 (743) 에서, 리소스는, 이전에 억제된 하나 이상의 요청들을 실행하기 위한 하나 이상의 조건들이 존재하는지 아닌지를 결정한다. 예를 들면, 아이들 상태로 들어가는 CPU (402) 에 관해 위에서 언급된 예시적인 시나리오에서, 리소스는, 하나의 조건으로서 CPU (402) 가 자신의 아이들 상태를 벗어났는지 아닌지를 결정할 수도 있다. 이 조건이 참이면 (CPU (402) 가 자신의 아이들 상태를 벗어났다는 것을 의미함), 리소스는 이전에 억제된 요청들을 실행할 수도 있다. 다시 말하면, 결정 블록 (743) 에 대한 질의가 긍정적이면, "예" 분기에 블록 (744) 이 후속할 수도 있고, 여기서는, 리소스는 이전에 억제된 하나 이상의 요청들을 실행한다. 본질적으로, 이 지점에서의 코드는, 억제 조건이 참이 되는 경우 (즉, CPU (402) 가 아이들 상태가 되는 경우) 새로운 상태가 무엇이 되어야 하는지를 계산하고 그것을 멀리 저장한다. 그 다음 그 조건이 참이 되면, 다른 상태를 적용한다. 이것은 당업자에 의해 이해되는 바와 같은 지연된 실행의 한 형태이다.

결정 블록 (743) 에 대한 질의가 부정적이면, "아니오" 분기에 결정 블록 (745) 이 후속한다. 결정 블록 (745) 에서, 리소스는, 억제가능한 것으로서 식별된 그들 요청들을 억제하기 위한 하나 이상의 조건들이 존재하는지 아닌지를 결정할 수도 있다. 결정 블록 (745) 은, CPU가 막 아이들 상태로 들어가려고 하는 이전 예와 대응할 수도 있다. 결정 블록 (745) 에 대한 질의가 긍정적이면, "예" 분기에 블록 (746) 이 후속할 수도 있고, 여기서는, 리소스는 리소스에 의한 나중의 실행을 위해 하나 이상의 억제가능한 요청들을 모을 수도 있다. 결정 블록 (745) 에 대한 질의가 부정적이면, "아니오" 분기에 블록 (747) 이 후속하는데, 여기에서, 방법 (700D) 은 도 7b의 블록 (753) 으로 리턴한다.

도 7e는 PCD (100) 에 대해 이용불가능하게 된 인스턴스화된 노드들 (601) 을 관리하기 위한 옵션적 방법 (700E) 을 도시하는 도 7a의 계속 흐름도이다. 이 옵션적 방법 (700E) 은, 옵션적 방법 (700E) 이 도 7a의 루틴 (725) 에 기초하여 이미 인스턴스화된 노드들 (601) 에 대한 것이다는 점을 제외하면, 옵션적 방법 (700C) 과 아주 유사하다.

이미 언급된 바와 같이, 노드의 리소스가 오프라인으로 취해지거나 장애 조건을 경험하게 된 경우 노드 (601) 는 이용불가능다고 특징지어질 수도 있다. 하나의 예시적인 양태에 따르면, 리소스가 디바이스의 USB 포트 타입과 같이 PCD (100) 로부터 제거될 수도 있는 하드웨어인 경우 리소스는 이용불가능하게 될 수도 있다. 하드웨어의 드라이버는 도 5의 프레임워크 매니저 (440) 에게, 언제 리소스가 PCD (100) 로부터 제거되었고 프레임워크 매니저 (440) 에 의해 관리될 수도 있는 임의의 요청들을 프로세싱하는 데 리소스가 언제 이용불가능하다는 것을 통지할 수도 있다.

이 옵션적 방법 (700E) 은, 옵션적 방법 (700C) 처럼, PCD (100) 에 커플링될 수도 있는 접속가능한/접속해제 가능한 타입의 리소스들에 아주 적합할 수도 있다. 이 옵션적 방법 (700D) 은, 도 7a의 루틴 블록 (725) 에서 인스턴스화되지 않거나 생성되지 않은 노드들 (601) 에 맞게 만들어진다. 다시 말하면, 옵션적 방법 (700E) 은, 프레임워크 매니저 (440) 에 의해 생성된 그리고 도 6a의 리소스 그래프 (500B1) 와 같은 리소스 그래프에 이미 존재하는 노드들 (601) 을 관리한다.

결정 블록 (766) 은, 도 7a의 블록 (721) 처럼, 옵션적 방법 (700D) 의 제 1의 단계이다. 결정 블록 (766) 에서, 프레임워크 매니저 (440) 는, 도 6a의 예시적인 노드 리소스 그래프 (500B1) 에서 도시된 바와 같이 특별한 노드 (601) 가 오프라인에서 취해져야 하는지 아닌지를 결정할 수도 있다. 이 결정 블록 (766) 에서, 도 5의 프레임워크 매니저 (440) 는, 프레임워크 매니저가 시스템 (500) 에 이용가능한 접속가능한 리소스들에 대한 디바이스 드라이버들로부터 수신할 수도 있는 메시지들을 모니터링하고 있을 수도 있다. 이전에 언급된 바와 같이, 시스템 (500) 에 이용가능한 접속가능한 리소스들을 관리하는 것에 추가하여, 옵션적 방법 (700E) 은, 장애 조건을 경험한 이들 리소스들을 또한 관리할 수도 있고 이것은 프레임워크 매니저 (440) 에 의해 시스템으로 전송되는 임의의 요청들을 떠맡거나 그 요청들에 대해 작용하는 것을 방지한다. 리소스의 디바이스 드라이버는, 결정 블록 (766) 에서, 프레임워크 매니저 (440) 에게, 프레임워크 매니저 (442) 가 리소스와 그것의 대응하는 노드 (601) 를 오프라인으로 취하는 것을 요구하는 장애 조건을 노드 (601) 의 특별한 리소스가 경험했는지 아닌지를 통지할 수도 있다.

결정 블록 (766) 에 대한 질의가 부정적이면, "아니오" 분기에 도 7a의 블록 (705) 이 후속한다. 결정 블록 (766) 에 대한 질의가 긍정적이면, "예" 분기에 결정 블록 (768) 이 후속한다.

블록 (768) 에서, 프레임워크 매니저 (440) 는 노드 (601) 가 오프라인으로 취해지기 이전에 노드 (601) 의 리소스의 현재 상태를 기록한다. 그 다음, 프레임워크 매니저 (440) 는 리소스와 그것의 대응하는 노드 (601) 를 오프라인으로 취할 수도 있다.

블록 (770) 에서, 프레임워크 매니저 (440) 는 하나 이상의 다른 리소스(들) 에 의한 액세스로부터 현존하는 노드 (601) 를 의존적 노드 (601) 로서 락한다. 다시 말하면, 프레임워크 매니저 (440) 는, 다른 노드들 (601), 스레드들, 클라이언트들 (648) 등에 의해 발행된 요청들을 프로세싱하는 시스템 (500) 에, 노드 (601) 의 하나 이상의 리소스들이 이용불가능한 경우, 다른 노드들 (601) 이 노드 (601) 를 참조하는 것을 방지한다.

블록 (772) 에서, 프레임워크 매니저 (440) 는 노드 (601) 와 그것의 현재 상태를 디스에이블한다. 결정 블록 (774) 에서, 프레임워크 매니저 (440) 는, 이용불가능한 하나 이상의 리소스들이 시스템 (500) 에 이용가능하게 되도록 상태를 변경했는지 아닌지를 결정하기 위해, 디스에이블된 노드 (601) 에 대한 리소스들의 하나 이상의 디바이스 드라이버들로 점검한다.

결정 블록 (774) 에 대한 질의가 부정적이면, "아니오" 분기에 도 7a의 블록 (705) 이 후속한다. 결정 블록 (774) 에 대한 질의가 긍정적이면, "예" 분기에 블록 (776) 이 후속하는데, 여기에서, 프레임워크 매니저 (440) 는 노드 (601) 를 인에이블시키고 그 결과 노드는 다시 시스템 (500) 에 이용가능하게 될 수 있다. 블록 (778) 에서, 현존하는 노드 (601) 가 재초기화되고 그 결과 자신의 이전 상태로 되돌아 간다. 다시 말하면, 현존 노드 (601) 는, 프레임워크 매니저 (440) 에 의해 오프라인으로 취해지기 바로 직전에 노드 (601) 가 있었던 상태로 노드 (601) 를 두기 위해 재초기화된다.

결정 블록 (780) 에서, 프레임워크 매니저 (440) 는 재인에이블된 여전히 인스턴스화되지 않은 노드 (601) 의 의존성들이 또한 인에이블되는지 아닌지를 결정할 수도 있다. 이 결정 블록 (728) 은, 재인에이블된 현존 노드 (601) 가 의존할 수도 있는 노드들 (601) 의 리소스들 또는 노드들 (601) 자신이 인에이블된 것을 프레임 매니저 (442) 가 확신하는 것을 허용한다. 결정 블록 (780) 에 대한 질의가 부정적이면, "아니오" 분기에 도 7a의 블록 (705) 이 후속한다.

결정 블록 (780) 에 대한 질의가 긍정적이면, "예" 분기에 블록 (782) 이 후속하는데, 여기에서, 재인에이블된 현존 노드 (601) 는 프레임워크 매니저 (440) 에 의해 언락된다. 재인에이블된 현존 노드 (601) 는, 도 6a의 리소스 그래프 (500B1) 에서 생성된 것과 같은 다른 리소스들에 의한 액세스를 위해 언락된다. 그 다음, 옵션적 방법 (700E) 은 도 7a의 블록 (705) 으로 리턴한다.

도 8은 PCD (100) 의 소프트웨어 아키텍쳐에서 노드 구조 데이터를 수신하기 위한 도 7의 서브 방법 또는 루틴 (705) 을 도시하는 흐름도이다. 결정 블록 (802) 은 도 8의 서브 방법 또는 루틴 (705) 에서의 제 1의 단계이다.

결정 블록 (802) 에서, 프레임워크 매니저 (440) 는, 노드 구조 데이터가 스터브 (stub) 리소스를 생성하기 위한 요청을 포함하는지 아닌지를 결정한다. 스터브 리소스는, 도 6a의 프레임워크 또는 리소스 그래프 (500B1) 에서 리소스 오써가 플레이스홀더를 생성하는 것을 허용하는 소프트웨어 개발 툴이다. 스터브 리소스는 다른 리소스들이 형성되는 것을 가능하게 할 수도 있고 다른 리소스들이 의존할 수도 있는 플레이스홀더이다. 이와 같이, 다른 리소스들과 궁극적으로는 노드들 및 클라이언트들은, 특별한 리소스가 이용가능하지 않거나 또는 아직 개발되지 않았을 때, 인스턴스화 루틴 (725) 동안 프레임워크 매니저 (440) 에 의해 생성될 수도 있다.

노드들의 다른 리소스들은 스터브 리소스들에 대한 이벤트들을 등록할 수도 있다. 그러나, 스터브 리소스들은, 스터브 리소스가 이벤트를 지원할 수도 있는 임의의 액티브한 기능들을 포함하지 않을 것이기 때문에 이벤트에 대한 값을 절대 리턴하지 않을 것이다. 스터브 리소스들은 나중의 스테이지에서 실제의 또는 작동 중인 리소스들로 대체될 수도 있다. 스터브 리소스들이 실제 리소스들로 어떻게 대체될 수도 있는지에 관한 추가적인 상세들은 도 17과 연계하여 하기에 설명될 것이다.

결정 블록 (802) 에 대한 질의가 부정적이면, "아니오" 분기에 결정 블록 (805) 이 후속한다. 결정 블록 (802) 에 대한 질의가 긍정적이면, "예" 분기에 블록 (803) 이 후속하는데, 여기에서, 프레임워크 매니저 (440) 는 스터브 리소스의 생성을 위한 상세한 명칭 및 데이터를 수신할 수도 있다. 그 다음, 프로세스 (705) 는 도 7a의 블록 (710) 으로 리턴한다.

블록 (805) 에서, 프레임워크 매니저 (440) 는, 도 5의 CPU (402) 및 클록 (442) 과 같은, 소프트웨어 또는 하드웨어 엘리먼트에 대한 고유의 명칭을 수신할 수도 있다. 앞서 논의된 바와 같이, 노드 (601) 는 적어도 하나의 리소스를 참조해야만 한다. 각각의 리소스는 명칭을 가지며 그 명칭은 시스템 (500) 에서 고유해야만 한다. 시스템 (500) 내의 모든 엘리먼트들은 고유 명칭들로 식별될 수도 있다. 각각의 엘리먼트는 문자적 관점에서 고유 명칭을 갖는다. 다시 말하면, 일반적으로, 시스템 (500) 내에 동일한 명칭을 갖는 어떠한 2개의 엘리먼트들도 존재하지 않는다.

시스템의 예시적인 양태들에 따르면, 노드들 (601) 의 리소스들은 시스템 전역에서 고유의 명칭들을 일반적으로 가질 수도 있지만, 클라이언트 또는 이벤트 명칭들은 필요에 따라 고유할 수도 있지만 고유해야만 할 필요는 없다.

편의상, 고유의 명칭들을 생성하기 위해 슬래시 (forward slash) "/"를 활용하는 종래의 트리 파일 네이밍 구조 또는 파일 네이밍 "메타포"가 활용될 수도 있다 (예컨대, CPU (402) 에 대한 "/core/cpu" 및 클록 (442) 에 대한 "/clk/cpu", 이들에 제한되지 않음). 그러나, 당업자에 의해 인식될 수 있는 바와 같이, 영숫자 문자들 및/또는 심볼들의 임의의 다른 조합을 포함하는 다른 타입들의 리소스 명칭들도 본 발명의 범위 내에 또한 있다.

다음으로, 블록 (810) 에서, 프레임워크 매니저 (440) 는 생성되고 있는 노드 (601) 의 하나 이상의 리소스들과 관련된 하나 이상의 드라이버 기능들에 대한 데이터를 수신할 수도 있다. 드라이버 기능은 특별한 노드 (601) 에 대한 하나 이상의 리소스들에 의해 완성될 액션을 일반적으로 포함한다. 예를 들면, 도 6에서, 노드 (602) 의 리소스 /core/cpu에 대한 드라이버 기능은, 요청된 프로세싱의 요청된 양을 제공하기 위해 필요로 하는 CPU 클록 주파수 및 버스 대역폭의 양을 요청할 수도 있다. 이들 요청들은 노드 (622) 및 노드들 (642) 에서의 리소스들의 클라이언트 (도시되지 않음) 를 통해 이루어질 것이다. 일반적으로, 노드 (642) 에서의 /clk/cpu에 대한 드라이버 기능은, 노드 (602) 의 /core/cpu 리소스로부터 노드 (642) 가 수신한 요청에 따라 물리적 클록 주파수를 실제 설정하는 것에 책임이 있을 것이다.

블록 (815) 에서, 프레임워크 매니저 (440) 는 노드 속성 데이터를 수신할 수도 있다. 노드 속성 데이터는, 일반적으로, 보안성 (유저 공간 어플리케이션들을 통해 노드가 액세스될 수 있음), 원격성 (시스템의 다른 프로세서들로부터 노드가 액세스될 수 있음), 및 접근성 (리소스가 다수의 동시적 클라이언트들을 지원할 수 있음) 과 같은 노드 정책들을 정의하는 데이터를 포함한다. 프레임워크 매니저 (440) 는, 요청 평가 또는 로깅 정책과 같은 디폴트의 프레임워크 거동을 리소스가 무시하는 (override) 것을 가능하게 하는 속성들을 또한 정의한다.

계속해서, 블록 (820) 에서, 프레임워크 매니저 (440) 는 생성되고 있는 특별한 노드 (601) 에 대한 커스터마이징된 (customized) 유저 데이터를 수신할 수도 있다. 유저 데이터는 "C" 프로그램 언어와 관련하여 당업자에 의해 이해되는 바와 같은 보이드 "스타" 필드를 포함할 수도 있다. 유저 데이터는 당업자에게 "트러스트 미 (trust me) " 필드로서 또한 알려져 있다. 예시적인 커스터마이징된 유저 데이터는 주파수 테이블들과 같은 테이블들, 레지스터 맵들 등을 포함할 수도 있지만 이들에 제한되는 것은 아니다. 블록 (820) 에서 수신된 유저 데이터는 시스템 (500) 에 의해 참조되지 않지만, 커스터마이징이 프레임워크 매니저 (440) 에 의해 인식되지 않거나 완전히 지원되지 않으면 리소스의 커스터마이징을 허용한다. 이 유저 데이터 구조는, 특별한 또는 특정한 사용들을 위해 확장되도록 의도된 "C" 프로그래밍 언어에서의 기본 클래스이다.

당업자는, 특별한 클래스의 특정 사용들을 확장하기 위한 다른 종류들의 데이터 구조들이 본 발명의 범위 내에 있다고 인지한다. 예를 들면, "C++ (C 플러스플러스) "의 프로그래밍 언어에서, 등가의 구조는 "public" 이라는 키워드를 포함할 수도 있는데, 이것은 노드 (601) 내의 리소스에 대한 확장 메커니즘이 될 것이다.

다음에, 블록 (825) 에서, 프레임워크 매니저 (440) 는 의존성 어레이 데이터를 수신할 수도 있다. 의존성 어레이 데이터는, 생성되고 있는 노드 (601) 가 의존하는 하나 이상의 리소스들 (601) 의 고유한 그리고 구체적인 명칭들을 포함할 수도 있다. 예를 들면, 도 6b의 제 1의 노드 (602) 가 생성되고 있었다면, 이 블록 (825) 에서, 의존성 어레이 데이터는, 제 1의 노드 (602) 가 의존하는 제 3의 노드 (642) 의 단일의 리소스 명칭과 제 2의 노드 (622) 의 세 개의 리소스들의 리소스 명칭들을 포함할 수도 있다.

계속해서, 블록 (830) 에서, 프레임워크 매니저 (440) 는 의존성 어레이 데이터를 수신할 수도 있다. 리소스 어레이 데이터는 생성되고 있는 현재의 노드에 대한 파라미터들, 예컨대 도 6의 제 1의 노드 (602) 가 생성되고 있다면, 이 제 1의 노드 (602) 에 관련된 파라미터들을 포함할 수도 있다. 리소스 어레이 데이터는 하나 이상의 다음의 데이터를 포함할 수도 있다: 다른 리소스들의 명칭들; 유닛; 최대 값; 리소스 속성들; 플러그인 데이터; 및 블록 (820) 의 커스터마이징된 유저 데이터와 유사한 임의의 커스터마이징된 리소스 데이터. 플러그인 데이터는 소프트웨어 라이브러리로부터 취출된 기능들을 일반적으로 식별하고 생성되고 있는 복수의 노드들 또는 특별한 노드에 의해 지원될 수도 있는 클라이언트 타입들을 보통 열거한다. 플러그인 데이터는 클라이언트 생성 및 파괴의 커스터마이징을 또한 허용한다. 블록 (830) 이후에, 프로세스는 도 7의 블록 (710) 으로 리턴한다.

도 8에서, 속성 데이터 블록 (815), 커스터마이징된 유저 데이터 블록 (820), 및 의존성 어레이 데이터 블록 (825) 은, 이들 특별한 단계들이 옵션적이며 임의의 주어진 노드 (601) 에 대해 필수적인 것이 아니라는 것을 나타내기 위해 점선들로 도시되어 있다. 한편, 고유 명칭 블록 (805), 드라이버 기능 블록 (810), 및 리소스 어레이 데이터 블록 (830) 은, 루틴 (705) 의 이들 단계들이 노드 (601) 생성을 위해 일반적으로 의무적이라는 것을 나타내기 위해 실선들로 도시되어 있다.

도 9는 PCD (100) 에 대한 소프트웨어 아키텍쳐에서 노드를 생성하기 위한 도 7의 루틴 (725) 을 도시하는 흐름도이다. 루틴 블록 (905) 은 하나의 예시적인 실시형태에 따라 노드 (601) 를 인스턴스화하거나 생성하기 위한 서브 방법 또는 루틴 (725) 에서의 제 1의 루틴이다. 루틴 블록 (905) 에서, 인스턴스화되고 있는 노드 (601) 와 관련된 하나 이상의 클라이언트들 (648) 은 이 단계에서 생성된다. 루틴 블록 (905) 에 대한 추가적인 상세들은 도 12와 연계하여 하기에 더 상세히 설명될 것이다.

블록 (910) 에서, 프레임워크 매니저는 블록 (705) 의 노드 구조 데이터에 대응하는 하나 이상의 리소스들을 생성하거나 인스턴스화할 수도 있다. 다음에, 블록 (915) 에서, 프레임워크 매니저 (440) 는, 루틴 블록 (705) 의 리소스 어레이 데이터 블록 (830) 에서 수신된 최대 값들을 사용하여 루틴 블록 (705) 의 루틴 블록 (810) 에서 수신된 드라이버 기능들을 활성화할 수도 있다. 하나의 예시적인 양태에 따르면, 드라이버 기능들은 루틴 블록 (705) 의 리소스 어레이 데이터 블록 (830) 에서 수신된 최대 값들을 사용하여 활성화될 수도 있다. 다른 양호한 예시적인 양태에 따르면, 각각의 드라이버 기능은, 루틴 (705) 으로부터의 노드 구조 데이터와 함께 전달되는 옵션적인 초기 값으로 활성화될 수도 있다. 초기 데이터가 제공되지 않으면, 드라이버 기능은 최소 값인 0에서 초기화된다. 또한, 드라이버 기능은 그것이 초기화되고 있다는 것이 알려지게 되는 방식으로 보통 활성화된다. 이것은 초기화에 특정하지만, 보통의 또는 루틴 동작 동안 수행될 필요가 없는 임의의 동작들을 리소스가 수행하는 것을 가능하게 한다. 그 다음, 프로세스는 도 7의 단계 730로 리턴한다.

도 10은 PCD (100) 에 대한 소프트웨어 아키텍쳐에 의해 유지될 수도 있는 예시적인 명칭 테이블 (1000) 에 대한 데이터 구조의 도면이다. 예시적인 명칭 테이블 (1000) 은 2개의 칼럼들의 데이터를 포함할 수도 있다. 제 1의 칼럼은 리소스들 (601) 에 대응하는 앨리어스들 (1005) 를 포함할 수도 있고 제 2의 칼럼은 도 6에 도시된 노드들 (601) 사이의 관계를 관리하기 위한 프레임워크 매니저 (440) 에 의해 유지되는 노드들 (601) 의 실제 리소스 명칭들 (1010) 을 포함할 수도 있다. 동일한 리소스 (601) 에 대해 다수의 앨리어스들이 사용될 수도 있다. 앨리어스는 의존성으로서 여겨질 수도 있고 도 12와 연계하여 하기에 설명되는 바와 같이 클라이언트의 생성 동안 생성될 수도 있다.

명칭 테이블 (1000) 은, 어떤 하드웨어 및/또는 소프트웨어 엘리먼트들에 집중된 제 1의 디자인 팀 (예컨대, 소프트웨어 드라이버들에 대한 주문자 상표 부착생산자 (OEM)) 이, 하드웨어 또는 소프트웨어의 특별한 피스에 대해 작업하고 있는 제 1의 디자인 팀에 대해 내부적인 고유 명칭들을 제공하는 것을 허용한다. 명칭 테이블 (1000) 을 통해, 제 2 및 제 3의 (또는 그 이상의) 외부 디자인 팀들은, 제 2 및 제 3의 외부 디자인 팀들의 하드웨어 또는 소프트웨어 엘리먼트들에 의해 선호되는 앨리어스들을 사용함으로써 (본 예에서는 OEM의) 제 1의 디자인 팀의 하드웨어 또는 소프트웨어 엘리먼트들을 참조할 수도 있다.

예를 들면, 도 10의 테이블 (1000) 의 제 1의 로우 및 제 2의 칼럼에 도시된 바와 같이, OEM은 도 5의 중앙 처리 유닛 (402) 에 대해 "/cpu 0"의 명칭을 할당할 수도 있다. 한편, OEM에 비해 전문가인 제 2의 팀은 동일한 중앙 처리 유닛 (402) 에 대해 상이한 명칭 또는 앨리어스를 할당하기를 소망할 수도 있다. 제 2의 팀은 도 10의 테이블 (1000) 의 제 1의 로우와 제 1의 칼럼에 도시된 바와 같이, "/cpu 0"의 리소스 명칭에 대응하는 "main processor"의 앨리어스를 할당할 수도 있다.

도 11은 PCD (100) 에 대한 소프트웨어 아키텍쳐에서 리소스의 앨리어스를 생성하는 방법 (1100) 을 도시하는 흐름도이다. 블록 (1105) 은 리소스 (601) 의 앨리어스 (1005) 를 생성하기 위한 방법 (1100) 에서 제 1의 단계이다. 블록 (1005) 에서, 프레임워크 매니저 (440) 는 리소스 (601) 의 특별한 명칭 (1010) 에 대응하는 유저에 의해 선택된 앨리어스 (1005) 를 수신한다. 다음에, 결정 블록 (1110) 에서, 프레임워크 매니저 (440) 는, 선택된 앨리어스에 의해 참조된 리소스가 프레임워크 매니저 (440) 에 의해 선택되었는지 아닌지를 결정한다. 앨리어스가 리소스에 대해 또는 다른 앨리어스에 대해 정의될 수도 있음을 당업자는 알 수 있을 것이다. 공표된 임의의 명칭은, 단지 리소스 명칭들이 아니라, 앨리어스화될 수도 있다.

결정 블록 (1110) 에 대한 질의가 부정적이면, "아니오" 분기에 블록 (1115) 이 후속하는데, 여기에서, 앨리어스는 리소스가 생성될 때까지 임시 스토리지에 저장된다. 구체적으로는, 정의되지 않은 명칭에 대한 앨리어스가 생성되면, 이 앨리어스는 메모리에 저장되고 프로세스는 더 많은 앨리어스들이 정의되는 것을 대기하는 것으로 되돌아 간다. 앨리어스가 인스턴스화되면, 앨리어스 명칭은 아직까지 정의되지 않은 명칭 (앨리어스) 에 대한 콜백과 함께 메모리에 저장된다. 그 정의되지 않은 명칭 (앨리어스가) 이 공표될 때, 그것은 앨리어스를 통지하고, 그 다음 그것이 공표되도록 한다. 이 거동은, 누락된 의존성이 존재하는 경우의 리소스 생성 프로세서와 본질적으로 동일하다.

그 다음, 프로세스는 블록 (1105) 으로 복귀한다. 결정 블록 (1110) 에 대한 질의가 긍정적이면, "예" 분기에 블록 (1120) 이 후속하는데, 여기에서, 앨리어스는 프레임워크 매니저 (440) 에 의해 공표되고 그 결과 다른 리소들은 방금 생성된 앨리어스에 대응하는 리소스를 액세스할 수도 있게 된다. 그 다음 프로세스는 리턴한다.

도 12는 PCD (100) 의 소프트웨어 아키텍쳐에서 클라이언트 (648) 를 생성하기 위한 도 9의 서브 방법 또는 루틴 (905) 을 도시하는 흐름도이다. 블록 (1205) 은, 하나 이상의 리소스들 (601) 의 클라이언트 (648) 가 생성되는 루틴 블록 (905) 의 제 1의 단계이다. 블록 (1205) 에서, 프레임워크 매니저 (440) 는 생성되고 있는 클라이언트 (648) 에 할당된 명칭을 수신한다. 리소스 명칭들과 마찬가지로, 클라이언트 (648) 에 대한 명칭은 임의의 타입의 영숫자 및/또는 심볼들을 포함할 수도 있다.

다음에, 블록 (1210) 에서, 커스터마이징된 유저 데이터는, 생성되고 있는 이 클라이언트 (648) 에 대한 임의의 특별한 커스터마이징이 존재하는 경우 프레임워크 매니저 (440) 에 의해 수신될 수도 있다. 블록 (1210) 은 그 단계가 옵션적이라는 것을 나타내기 위해 점선들로 도시되었다. 블록 (1210) 의 커스터마이징된 유저 데이터는, 노드들 (601) 에 대한 리소스들의 생성과 관련하여 위에서 설명된 커스터마이징된 유저 데이터와 유사하다.

블록 (1215) 에서, 프레임워크 매니저 (440) 는 생성되고 있는 특별한 클라이언트에 할당된 클라이언트 타입 카테고리를 수신한다. 이 글을 쓰는 시점에서의 클라이언트 타입 카테고리는 4개의 타입들: (a) 필수 (required), (b) 임펄스, (c) 벡터, 및 (d) 등시성 (isochronous) 중 하나를 포함할 수도 있다. 클라이언트 타입 카테고리 리스트는 시스템 (500) 에 의해 관리되고 있는 리소스들에 의존하여 그리고 노드들 (601) 의 리소스들에 의존하는 어플리케이션 프로그램들에 의존하여 확장할 수도 있다.

필수 카테고리는 필수 클라이언트 (648) 로부터 특별한 리소스 (601) 로 전달되는 스칼라 값의 프로세싱과 일반적으로 부합한다. 예를 들면, 필수 요청은 어떤 수의 MIPs를 포함할 수도 있다. 한편, 임펄스 카테고리는, 시작 시간 또는 정지 시간의 임의의 지정 없이 어떤 기간 내에 몇몇 액티비티의 완료 요청의 프로세싱과 일반적으로 부합한다.

등시성 카테고리는, 통상적으로 재발생하며 잘 정의된 시작 시간과 잘 정의된 종료 시간을 갖는 액션에 대한 요청과 일반적으로 부합한다. 벡터 카테고리는, 보통, 직렬로 또는 병렬로 요구되는 다수의 액션들 중 일부인 데이터의 어레이와 일반적으로 부합한다.

계속해서, 블록 (1220) 에서, 프레임워크 매니저 (440) 는, 클라이언트 (648) 가 동기적인 것으로서 지정되었는지 또는 비동기적인 것으로서 지정되었는지를 나타내는 데이터를 수신한다. 동기적 클라이언트 (648) 는, 리소스 (601) 가 데이터를 리턴할 때까지 프레임워크 매니저 (442) 가 노드 (601) 의 리소스를 락하는 것과 리소스 (601) 가 동기적 클라이언트 (648) 로부터의 요청된 작업의 완료를 종료하였는지의 표시를 통상 요구하는 것이다.

한편, 비동기적 클라이언트 (648) 는, 프레임워크 매니저 (440) 에 액세스되는 하나 이상의 스레드들 (436) (도 4 참조) 에 의해 병렬적으로 핸들링될 수도 있다. 프레임워크 매니저 (440) 는 스레드 (436) 에 대한 콜백을 생성할 수도 있고 콜백이 각각의 스레드 (436) 에 의해 실행된 경우 값을 리턴할 수도 있다. 동기적 클라이언트 (648) 의 작업이 실행되고 있을 때 동기적 클라이언트 (648) 가 하는 것처럼 비동기적 클라이언트 (648) 는 리소스를 락업하지 않음을 당업자는 알고 있다.

블록 (1220) 이후, 결정 블록 (1225) 에서, 프레임워크 매니저 (440) 는 클라이언트 (645) 에 의해 식별된 리소스가 이용가능한지 아닌지를 결정한다. 결정 블록 (1225) 에 대한 질의가 부정적이면, "아니오" 분기에 블록 (1230) 이 후속하는데, 여기에서는, 클라이언트 (648) 가 이 시점에서 생성될 수 없음을 나타내는 널 값 또는 메시지가 유저에게 리턴된다.

결정 블록 (1225) 에 대한 질의가 긍정적이면, "예" 분기에 결정 블록 (1235) 이 후속하는데, 여기에서, 프레임워크 매니저 (440) 는, 클라이언트 (648) 에 의해 식별된 각각의 리소스가 블록 (1210) 에서 제공된 클라이언트 타입을 지원하는지 아닌지를 결정한다. 결정 블록 (1235) 에 대한 질의가 부정적이면, "아니오" 분기에 블록 (1230) 이 후속하는데, 여기에서, 클라이언트 (648) 가 이 시점에서 생성될 수 없음을 나타내는 널 값 또는 메시지가 리턴된다.

결정 블록 (1235) 에 대한 질의가 긍정적이면, "예" 분기에 블록 (1240) 이 후속하는데, 여기에서, 프레임워크 매니저 (440) 는 메모리의 클라이언트 (648) 를 생성하거나 인스턴스화한다. 다음에, 블록 (1245) 에서, 임의의 커스터마이징된 유저 데이터, 예컨대 옵션적인 인수들 (arguments) 이 블록 (1210) 에서 수신되면, 이들 옵션적인 인수들은 특별한 노드들 (601) 의 그들 각각의 리소스들과 매핑될 수도 있다. 다음에, 블록 (1250) 에서, 새롭게 생성된 클라이언트 (645) 는, 위에서 설명된 도 6b에 도시된 바와 같이, 요청된 상태에 있는 또는 아이들 상태에 있는 그것의 대응하는 하나 이상의 리소스들에 커플링된다. 그 다음, 프로세스는 도 9의 단계 910으로 리턴한다.

도 13은 PCD (100) 에 대한 소프트웨어 아키텍쳐에서 리소스 (601) 에 대한 클라이언트 요청 (675) 을 생성하는 방법 (1300) 을 도시하는 흐름도이다. 이 방법 (1300) 은, 도 7 및 도 12와 연계하여 위에서 설명된 바와 같이 클라이언트 생성 및 노드 생성 후에 일반적으로 실행된다. 블록 (1305) 은, 리소스 (601) 에 대한 클라이언트 요청 (675) 을 생성하기 위한 방법 (1300) 에서의 제 1의 단계이다. 이 방법 (1300) 은, 다음의 요청들 (675) 의 3개의 타입들: (a) 필수, (b) 임펄스, 및 (c) 벡터가 프레임워크 매니저 (440) 에 의해 어떻게 핸들링되는지를 설명할 것이다. 요청 (675) 의 제 4의 타입의 요청, 즉 (d) 등시성 요청의 핸들링은 도 15와 연계하여 하기에 설명될 것이다. 위에서 언급된 요청들 (675) 의 명칭들이 나타내는 바와 같이, 클라이언트 요청들 (675) 은 도 12와 연계하여 위에서 설명되고 생성되었던 클라이언트 타입들과 일반적으로 부합한다.

블록 (1305) 에서, 프레임워크 매니저 (440) 는, 위에서 언급된 3개: (a) 필수, (b) 임펄스, 및 (c) 벡터 중 하나와 같은 특별한 클라이언트 요청 (675) 과 관련된 데이터를 수신할 수도 있다. 필수 요청과 관련된 데이터는, 일반적으로, 필수 클라이언트 (648) 로부터 특별한 리소스 (601) 로 전달되는 스칼라 값을 포함한다. 예를 들면, 필수 요청은 어떤 수의 MIPs (millions of instructions per second) 를 포함할 수도 있다. 한편, 임펄스 요청은, 시작 시간 또는 정지 시간의 임의의 지정 없이 어떤 기간 내에 몇몇 액티비티의 완료 요청을 포함한다. 벡터 요청에 대한 데이터는, 일반적으로, 직렬로 또는 병렬로 완료되도록 요구되는 다수의 액션들의 어레이를 포함한다. 벡터 요청은 임의의 길이의 값들을 포함할 수도 있다. 벡터 요청은, 보통, 사이즈 값과 값들의 어레이를 구비한다. 노드 (601) 의 각각의 리소스는, 벡터 요청을 지원하기 위해 포인터 필드를 갖도록 확장될 수도 있다. "C" 프로그래밍 언어에서, 포인터 필드는 당업자에 의해 이해되는 바와 같이 유니온 함수에 의해 지지된다.

클라이언트 요청 데이터는, 요청이 억제가능한지 또는 아닌지를 또한 나타낼 수도 있다. 억제가능한 요청들은, 도 7d의 방법 (700D) 과 연계하여 위에서 설명된 바와 같이 리소스 자체의 선택에 따라 리소스에 의해 상이하게 핸들링될 수도 있다.

다음에, 블록 (1310) 에서, 프레임워크 매니저 (440) 는, 도 13과 연계하여 위에서 설명된 방법에 의해 생성되었던 클라이언트 (648) 를 통해 요청을 발행한다. 계속해서, 블록 (1315) 에서, 프레임워크 매니저 (440) 는, 요청이 필수 타입이거나 또는 벡터 타입이면 클라이언트를 통해 전달되고 있는 요청 데이터를 이중으로 버퍼링한다 (double buffer). 요청이 임펄스 타입이면, 블록 (1315) 은 프레임워크 매니저 (1440) 에 의해 스킵된다.

요구된 요청들에 대해, 이 블록 (1315) 에서, 이전 요청으로부터의 값들은 메모리에 유지되고, 그 결과 프레임워크 매니저 (440) 는 요청된 값들의 현재 세트에서 이전에 요청된 값들 사이에 임의의 차이가 있는지 없는지를 결정할 수 있게 된다. 벡터 요청들에 대해, 노드 (601) 의 리소스는 특별한 구현을 위해 소망에 따라 그것을 유지할 수도 있지만, 이전 요청들은, 보통, 메모리에 유지되지 않는다. 따라서, 블록 (1315) 은 요청들의 벡터 타입들에 대해 옵션적이다.

블록 (1320) 에서, 프레임워크 매니저 (440) 는 요청된 값들의 현재 세트와 요청된 값들의 이전 세트 사이의 차이 또는 델타를 계산한다. 결정 블록 (1325) 에서, 프레임워크 매니저는, 요청된 값들의 현재 세트가 요청된 값들의 이전 세트와 동일한지 아닌지를 결정한다. 다시 말하면, 프레임워크 매니저 (440) 는, 요청된 값들의 현재 세트와 요청된 값들의 이전 세트 사이에 차이가 존재하는지 아닌지를 결정한다. 요청된 값들의 현재 세트와 이전 세트 사이에서 차이가 존재하지 않으면, "예" 분기에 블록 (1375) 이 후속하고 (블록들 (1330 내지 1370) 을 스킵함), 여기서는, 프로세스가 종료한다.

결정 블록 (1325) 에 대한 질의가 부정적이면 (요청된 값들의 세트가 이전에 요청된 값들의 세트에 대해 상이하다는 것을 의미함), "아니오" 분기에 결정 블록 (1330) 이 후속한다.

결정 블록 (1330) 에서, 프레임워크 매니저 (440) 는 현재 요청이 비동기적 요청인지 아닌지를 결정한다. 결정 블록 (1330) 에 대한 질의가 부정적이면, "아니오" 분기에 블록 (1340) 이 후속하고, 여기에서, 클라이언트 요청 (675) 에 대응하는 리소스 (601) 는 프레임워크 매니저 (440) 에 의해 락된다. 결정 블록 (1330) 에 대한 질의가 긍정적이면 (현재 요청이 비동기적 요청 타입임을 의미함), "예" 분기에 블록 (1335) 이 후속하는데, 여기에서, 멀티코어 시스템이, 도 4의 것처럼, 프레임워크 매니저 (440) 에 의해 현재 관리되면, 요청은 다른 스레드 상으로 푸시될 수도 있고 다른 코어에 의해 실행될 수도 있다. 블록들 (1335) 은, PCD (100) 가 싱글 코어 중앙 처리 시스템이면 이 단계가 옵셔적일 수도 있다는 것을 나타내기 위해, 점선들로 도시되어 있다.

계속해서, 블록 (1340) 에서, 요청 (675) 에 대응하는 리소스들 (601) 은 프레임워크 매니저 (440) 에 의해 락된다. 다음에, 블록 (1345) 에서, 리소스 (601) 는 도 8의 블록 (830) 에서 수신된 리소스 어레이 데이터의 플러그인 데이터에 일반적으로 대응하는 업데이트 기능을 실행한다. 업데이트 기능은, 일반적으로, 새로운 클라이언트 요청을 허용하여 새로운 리소스 상태를 책임지는 기능을 포함한다. 업데이트 기능은 자신의 이전 상태를 클라이언트 요청에서 요청된 상태와 비교한다. 요청된 상태가 이전 상태보다 더 크면, 업데이트 기능은 클라이언트 요청을 수행할 것이다. 그러나, 요청된 상태가, 리소스가 동작하고 있는 현재 상태 이하이면, 이전 상태가 요청된 상태를 달성하거나 만족하기 때문에 효율성을 증가시키기 위해 클라이언트 요청은 수행되지 않을 것이다. 업데이트 기능은 클라이언트로부터 새로운 요청을 취하고 모든 다른 액티브한 요청들과 함께 그것을 모아서 리소스에 대한 새로운 상태를 결정한다.

예로서, 다수의 클라이언트들은 버스 클록 주파수를 요청하고 있을 수도 있다. 버스 클록에 대한 업데이트 기능은, 보통, 모든 클라이언트 요청들의 최대값을 취하고 버스 클록에 대한 새롭게 소망된 상태로서 그것을 사용할 것이다. 다수의 리소스들에 의해 사용될 몇몇 업데이트 기능들이 존재하지만, 모든 리소스들이 동일한 업데이트 기능을 사용할 것은 아니다. 몇몇 공통의 업데이트 기능들은 클라이언트 요청들의 최대값을 취하고, 클라이언트 요청들의 최소값을 취하고 그리고 클라이언트 요청을 합산할 것이다. 또는 리소스들은, 그들의 리소스가 몇몇 고유한 방식으로 요청들을 모아야 할 필요가 있으면, 그들 자신의 커스텀 업데이트 기능을 정의할 수도 있다.

다음에, 블록 (1350) 에서, 프레임워크 매니저 (440) 는 그 데이터를 클라이언트 요청 (648) 에 대응하는 리소스에 전달하고, 그 결과 리소스는 노드 (601) 의 리소스에 특정한 드라이버 기능을 실행할 수도 있게 된다. 드라이버 기능은 업데이터 기능에 의해 계산된 바와 같은 리소스 상태를 적용한다. 이것은 하드웨어 설정들을 업데이트하고, 의존성 리소스들에 요청들을 발행하고, 리거시 기능들 또는 상기의 몇몇 조합을 호출하는 것을 수반할 수도 있다.

이전의 예에서, 업데이트 기능은 요청된 버스 클록 주파수를 계산했다. 드라이버 기능은 그 요청된 주파수를 수신하고 그것은 그 주파수에서 동작하도록 클록 주파수 제어 HW를 업데이트할 수도 있다. 가끔, 업데이트 기능이 계산한 정확하게 요청된 상태를 드라이버 기능이 충족하지 못할 수도 있음을 주목해야 한다. 이 경우, 드라이버 기능은 요청을 가장 잘 충족하는 주파수를 선택할 수도 있다. 예를 들면, 버스 클록 HW는 128MHz와 160MHz에서만 작동할 수도 있지만, 요청된 상태는 150MHz일 수도 있다. 이 경우, 드라이버 기능은, 요청된 상태를 초과한 것이긴 하지만, 160MHz에서 동작해야만 한다.

다음에, 블록 (1355) 에서, 프레임워크 매니저 (440) 는, 블록 (1350) 에서 드라이버 기능을 수행한 리소스로부터 상태 제어를 수신한다. 계속해서, 블록 (1360) 에서, 리소스에 대해 정의되면, 이벤트들 (690) 이 트리거되어, 그 결과 데이터는 이벤트 (690) 에 대응하는 클라이언트 (648) 로 다시 전달되게 된다. 이벤트들은 다른 스레드에서 프로세싱될 수도 있다. 이것은, 락된 리소스들에 의해 소비되는 시간의 양을 최소화할 수도 있고 도 4에 도시된 바와 같은 멀티코어 시스템에서 더 많은 병렬 동작을 허용한다. 하나 이상의 이벤트들 (690) 은, 이 방법 (1300) 에서 설명된 바와 같이 리소스에 대해 요청이 어떻게 정의될 수도 있는지와 유사한 방식으로 리소스에 대해 정의될 수도 있다. 다시 말하면, 이벤트 생성 프로세스는 클라이언트 생성 프로세스와 주로 유사하다. 이벤트들에 대해 상이한 하나는, 어떤 임계치들이 교차되는 경우에만 트리거되는 이벤트들을 정의할 수 있다는 것이다.

임계치들에만 기초하여 트리거되는 이벤트들의 이러한 정의는, 리소스가 언제 신청초과되는지 (지원할 수 있는 것보다 더 많은 동시 이용자를 갖는지) (이것은 시스템 과부하 상태를 나타낸다), 또는 리소스가 언제 모자라고/없어지는지 (이것은 다른 것들이 셧오프되는 것을 허용하는 것, 시스템이 신청초과되었을 때 디스에이블되었던 기능을 복원하는 것 등등을 할 수도 있다) 의 통지를 허용한다. 이벤트 등록이 임계치를 통해 행해질 수도 있기 때문에, 실제 뭔가 필요한 것이 존재하는 경우에만 발생하는 이벤트 통지에 대해 시스템이 해야만 하는 작업의 양을 감소시킨다. 또한, 모든 상태 변화에 대한 이벤트에 대해 등록하는 것도 가능하다.

다음에, 옵션적 블록 (1365) 에서, 프로세싱되고 있는 요청이 벡터 요청이면, 이 옵션적 블록 (1365) 은 일반적으로 수행된다. 옵션적 블록 (1365) 은, 일반적으로, 유저가 벡터로 전달했던 동일한 데이터 상에 벡터 포인터가 여전히 위치되어 있는지의 여부를 평가하기 위한 점검 또는 결정을 포함한다. 이 옵션적 블록 (1365) 에 대한 질의가 긍정적이면 (유저에 의해 벡터로 전달되었던 동일한 데이터를 포인터가 여전히 가리키고 있음을 의미), 포인터는 지워지고 그 결과 이전 데이터에 대한 참조들은 유지되지 않게 된다. 일반적으로, 이 옵션적 블록 (1365) 은, 임펄스 요청 및 필수 요청과 비교하여, 벡터 요청이 프로세싱되고 있을 때 위에서 설명된 이중 버퍼링 블록 (1315) 을 설명하기 위해 수행된다.

계속해서, 블록 (1370) 에서, 프레임워크 매니저 (440) 는 요청된 리소스를 언락하고, 그 결과 다른 클라이언트 요청들 (648) 은 특별한 노드 (601) 의 현재의 그러나 지금 릴리스된 요청된 리소스에 의해 핸들링될 수도 있다. 그 다음, 프로세스는 다음 클라이언트 요청을 수신하기 위해 제 1의 블록 (1305) 으로 리턴한다.

도 14는 PCD (100) 의 리소스에 대한 등시성 클라이언트 요청에서 요청된 작업을 도시하는 도면 (1400) 이다. 도면 (1400) 은 X축과 Y축을 구비하는 그래프를 포함한다. X축은, 일반적으로, 경과된 시간을 포함하고 반면 Y축은 요청된 MIPs와 같은 요청된 액션 값을 포함할 수도 있다. 이전에 언급된 바와 같이, 등시성 클라이언트 요청은, 일반적으로, 잘 정의된 시작 시간 A와 잘 정의된 종료 시간 또는 데드라인 C를 포함한다. 도 14에 도시된 예시적인 실시형태에서, 그래프는, 150MIPs의 요청된 작업이 시간 A에서 시작되어 시간 B에서 종료되었음을 나타내며, 여기서 시간 B는 요청된 데드라인 시간 C 이전에 발생했다.

도 15는 PCD (100) 에 대한 소프트웨어 아키텍쳐에서 리소스에 대한 등시성 클라이언트 요청을 생성하기 위한 도 9의 서브 방법 또는 루틴 (1300B) 을 도시하는 흐름도이다. 이 서브 방법 또는 루틴 (1300B) 은 도 13과 연계하여 위에서 설명된 단계들과 연계하여 실행되거나 이들 단계들과 별도로 구축된다. 이것은, 도 15에서 열거된 단계들이 도 13에서 제공된 도면 부호들에 대응하는 시퀀스에 위치됨을 의미한다. 하기에 더 상세히 설명되는 바와 같이, 본 발명은, 단계들의 순서 또는 시퀀스가 실행된 단계들로부터의 소망하는 출력에 영향을 주지 않는 경우 이러한 순서 또는 시퀀스에 제한되지 않는다.

블록 (1307) 은 등시성 요청들 (675) 을 프로세싱하기 위한 서브 방법 또는 루틴의 제 1의 단계이다. 블록 (1307) 은 도 13의 블록 (1305) 이후에 그리고 블록 (1310) 이전에 발생한다. 블록 (1307) 에서, 프레임워크 매니저 (440) 는 도 14와 연계하여 위에서 설명된 바와 같이 데드라인 C와 같은 데드라인 데이터를 수신할 수도 있다.

다음에, 블록 (1309) 에서, 프레임워크 매니저 (440) 는 블록 (1307) 에서 제공된 데드라인과 현재 시간 사이의 차이를 계산할 수도 있다. 계속해서, 도 13의 블록 (1360) 이후에 그리고 블록 (1365) 이전에 발생하는 블록 (1362) 에서, 프레임워크 매니저 (440) 는 시작 시간 A와 종료 시간 B를 데드라인 C와 비교한다 (도 14 참조). 블록 (1363) 에서, 프레임워크 매니저 (440) 가 요청된 액티비티의 양을 제공받았기 때문에 그리고 프레임워크 매니저 (440) 가 시작 시간 A와 종료 시간 B를 추적하기 때문에, 블록 (1363) 에서, 프레임워크 매니저 (440) 는 특별한 노드 (601) 의 리소스에 의해 수행되었던 작업의 양을 계산할 수도 있다.

다음에, 도 13의 블록 (1365) 이후에 그리고 블록 (1370) 이전에 발생하는 블록 (1367) 에서, 최적화 프로세스가 실행될 수도 있다. 블록 (1367) 은 그 단계가 옵션적이거나 또는 이 단계가 PCD (100) 에 대해 오프라인으로 그리고 오프 디바이스로 수행될 수도 있다는 것을 나타내기 위해 점선들로 도시되었다. 최적화 프로세스는, 소비 전력 및 응답성과 같은 많은 상이한 변수들을 고려하면서, 데드라인과 시작 시간 사이에서 작업이 어떻게 최상으로 완료될 수도 있는지를 결정하려고 시도할 수도 있다. 몇몇 예시적인 실시형태들에서, 이 블록 (1367) 은 본 발명의 범위를 벗어나지 않으면서 아주 완전히 스킵될 수도 있다. 그 다음, 프로세스는 다음 클라이언트 요청 (675) 을 프로세싱하기 위해 도 13의 블록 (1305) 으로 리턴한다.

도 16은 PCD (100) 에 대한 소프트웨어 아키텍쳐 (500) 에서 리소스에 대한 임계치 이벤트 (690) 를 생성하는 방법 (1600) 을 도시하는 흐름도이다. 도 16은 도 6c, 도 6d와 연계하여 위에서 설명된 임계치 이벤트들 (690) 과 일반적으로 부합한다. 이전에 언급된 바와 같이, 도 6c에 도시된 임계치 이벤트들 (690) 이 온도에 관련되지만, 임계치 이벤트들은 PCD (100) 내에서 모니터링될 수도 있는 임의의 타입의 조건과 관련될 수도 있다는 것을 당업자는 알고 있다.

예를 들면, 다른 임계치 이벤트들은, 소비 전력, 배터리 충전 스테이터스/상태, 슬립 또는 저전력 조건들, 양호한, 보통의, 불량의 RF (radio-frequency) 수신과 같은 특정 하드웨어 조건들, MIPs와 같은 부하들에 관련될 수도 있는 동작 조건들, 클록 주파수, 버스 주파수, 전압, DCVS 상태들 및 알고리즘 등을 포함하지만, 이들에 제한되는 것은 아니다. 임계치 이벤트들 (690) 은 보통 하나 이상의 트리거링 조건들을 포함한다. 도 6c에 도시된 예에서, 트리거하는 조건들은 특정 온도 값들에 관련되었다.

이제 도 16을 참조하면, 블록 (1605) 은 하나 이상의 임계치 이벤트들 (690) 을 생성하기 위한 방법 (1600) 의 제 1의 단계이다. 방법 (1600) 은, 일반적으로, 도 7에 도시된 바와 같은 PCD (100) 의 리소스들을 관리하기 위한 방법 (700) 이후에 수행되거나 실행된다. 블록 (1605) 에서, 도 5a의 프레임워크 매니저 (440) 는 노드 (601) 의 리소스에 대해 임계치 이벤트 (690) 를 생성하기 위해 하나 이상의 요청들을 수신할 수도 있다.

위에서 언급된 바와 같이, 프레임워크 매니저 (440) 에 의해 지원되는 소프트웨어 아키텍쳐 (500) 의 임의의 유저는 리소스에 대해 임계치 이벤트 (690) 를 셋업할 수도 있다. 임계치 이벤트들 (690) 을 생성하는 소프트웨어 아키텍쳐 (500) 의 유저는 리소스 오써 (resource author), 노드 오써, 리소스, 또는 실행 스레드 (thread of execution) 를 포함할 수도 있다. 임계치 이벤트 (690) 에 할당된 리소스들은 하나 이상의 상이한 리소스들로 임계치 이벤트의 스테이터스를 보고하도록 지시될 수도 있다.

다음에, 블록 (1610) 에서, 프레임워크 매니저 (440) 는, 노드 (601) 의 하나 이상의 리소스들에 대한 이벤트들/조건들을 추적하는 하나 이상의 기능들을 수신할 것이다. 이 블록 (1610) 은, 일반적으로, 도 6c에 도시된 임계치 이벤트들 (690) 과 부합한다. 블록 (1615) 에서, 프레임워크 매니저 (440) 는 하나 이상의 기능들에 의해 추적되고 있는 하나 이상의 임계치들 또는 조건들을 수신할 것이다. 구체적으로는, 블록들 (1610 및 1615) 에 대해, 프레임워크 매니저 (440) 는 도 6c에 도시된 임계치 이벤트들 (690A 내지 690D) 중 하나를 수신할 것이다. 도 6c에 도시된 각각의 임계치 이벤트들 (690) 은 온도 모니터링 기능을 가지며 특정 온도는 이 기능에 의해 추적된다.

다음에, 블록 (1620) 에서, 프레임워크 매니저 (440) 는 임계치 이벤트들의 통지들을 수신할 하나 이상의 리소스들의 하나 이상의 명칭들을 수신할 것이다. 블록 (1620) 은, 일반적으로, 도 6d에 도시된 차트 (697) 와 부합한다. 차트 (697) 는 제 2의 칼럼에서 열거된 임계치 이벤트들에 대한 수신측 리소스들을 제 3의 칼럼에 열거한다.

다음에, 블록 (1625) 에서, 리소스에 대한 하나 이상의 임계치 이벤트들은 프레임워크 매니저 (440) 에 의해 등록된다. 그 다음, 블록 (1630) 에서, 각각의 리소스는 방법 (1600) 에서 정의된 자신의 임계치 이벤트들의 자신의 모니터링을 시작한다. 그 다음 방법 (1600) 은 리턴한다.

도 17은 PCD (100) 에 대한 소프트웨어 아키텍쳐 (500) 에서 스터브 리소스를 새로운 (실제) 리소스로 대체하는 방법 (1700) 을 도시하는 흐름도이다. 도 17은, 일반적으로, 스터브 리소스가 생성될 수도 있는 도 8의 블록 (803) 과 부합한다. 도 8과 연계하여 이전에 언급된 바와 같이, 스터브 리소스는, 도 6a의 리소스 그래프 (500B1) 또는 프레임워크에서 리소스 오써가 플레이스홀더를 생성하는 것을 허용하는 소프트웨어 개발 툴이다. 스터브 리소스는 다른 리소스들이 형성되는 것을 가능하게 할 수도 있고 다른 리소스들이 의존할 수도 있는 플레이스홀더이다. 이와 같이, 다른 리소스들과 궁극적으로는 노드들 및 클라이언트들은, 특별한 리소스가 이용가능하지 않거나 아직 개발되어 있지 않은 경우에도 생성될 수도 있다.

노드들의 다른 리소스들은 스터브 리소스들에 대한 이벤트들을 등록할 수도 있다. 그러나, 스터브 리소스들은, 스터브 리소스가 이벤트를 지원할 수도 있는 임의의 액티브한 기능들을 포함하지 않을 것이기 때문에 이벤트에 대한 값을 절대 리턴하지 않을 것이다. 스터브 리소스들은 도 17에서 나타내어진 바와 같이 실제의 또는 작동하고 있는 리소스들로 대체될 수도 있다.

블록 (1705) 은 새롭게 (실제) 기능하는 리소스로 스터브 리소스를 대체하기 위한 방법 (1700) 의 제 1의 단계이다. 블록 (1705) 에서, 프레임워크 매니저 (440) 는, 스터브 리소스가 의존하는 하나 이상의 리소스들의 식별자 (identity) 를 수신할 수도 있다. 다음에, 블록 (1710) 에서, 프레임워크 매니저 (440) 는 스터브 리소스들이 의존하는 하나 이상의 리소스들을 락할 수도 있고, 그 결과 이들 다른 리소스들은 임의의 추가적인 요청들을 발행하지 못하게 될 수도 있게 된다.

다음에, 블록 (1715) 에서, 서터브 리소스에 대한 데이터 구조에 열거된 각각의 클라이언트는, 스터브 리소스를 대체할 새롭게 기능하는 리소스의 리스트에 추가될 수도 있다. 블록 (1720) 에서, 스터브 리소스의 각 클라이언트의 포인터는, 그것이 스터브 리소스를 대체하고 있는 새롭게 기능하는 리소스를 가리키도록 조정된다.

블록 (1725) 에서, 프레임워크 매니저 (440) 는 이전 스터브 리소스에 의존하는 각각의 리소스에 대해 하나 이상의 액티브한 요청들을 발행할 수도 있다. 다음에, 블록 (1730) 에서, 프레임워크 (440) 는 이전 스터브 리소스를 대체하고 있는 새로운 리소스의 새로운 상태를 재수집할 수도 있다. 다음에, 블록 (1735) 에서, 블록 (915) 에서, 프레임워크 매니저 (440) 는, 루틴 블록 (705) 의 리소스 어레이 데이터 블록 (830) 에서 수신된 최대 값들을 사용하여 루틴 블록 (705) 의 루틴 블록 (810) 에서 수신된 드라이버 기능들을 활성화할 수도 있다.

하나의 예시적인 양태에 따르면, 드라이버 기능들은 루틴 블록 (705) 의 리소스 어레이 데이터 블록 (830) 에서 수신된 최대 값들을 사용하여 활성화될 수도 있다. 다른 양호한 예시적인 양태에 따르면, 각각의 드라이버 기능은, 루틴 (705) 으로부터의 노드 구조 데이터와 함께 전달되는 옵션적인 초기 값으로 활성화될 수도 있다. 초기 데이터가 제공되지 않으면, 드라이버 기능은 최소 값인 0에서 초기화된다. 또한, 드라이버 기능은 그것이 초기화되고 있다는 것이 알려지게 되는 방식으로 보통 활성화된다. 이것은 초기화에 특정하지만, 보통의 또는 루틴 동작 동안 수행될 필요가 없는 임의의 동작들을 리소스가 수행하는 것을 가능하게 한다.

다음에, 블록 (1740) 에서, 프레임워크 매니저 (440) 는, 스터브 리소스를 대체하는 새롭고 기능적인 리소스에 대해, 스터브 리소스에 대해 이전에 등록되었던 하나 이상의 이벤트들을 재발행할 수도 있다. 그 다음 프로세스 (1700) 는 리턴한다.

본 명세서에서 설명된 프로세스들 또는 프로세스 플로우들에서의 어떤 단계들은, 본 발명이 설명된 바와 같이 기능하도록 다른 것들에 본질적으로 선행한다. 그러나, 본 발명은, 이러한 순서 또는 시퀀스가 본 발명의 기능을 변경하지 않으면 설명된 단계들의 순서에 제한되지 않는다. 즉, 본 발명의 취지와 범위를 벗어나지 않으면서, 몇몇 단계들은 다른 단계들 이전에, 이후에, 병행하여 (실질적으로는 동시에) 수행될 수도 있다. 몇몇 경우들에서, 어떤 단계들은, 본 발명에서 벗어나지 않으면서, 생략되거나 수행되지 않을 수도 있다. 또한, "그 후", "그 다음", "다음에" 등과 같은 단어들은 단계들의 순서를 제한하려는 의도는 아니다. 이들 단어들은, 단순히, 독자들을 인도하여 본 방법 단계들의 설명을 이해시키기 위해 사용된다.

추가적으로, 프로그래밍에서의 당업자는, 예를 들면, 본 명세서에서의 흐름도들 및 관련 설명들에 기초하여, 어려움 없이, 개시된 발명을 구현하기 위한 적절한 하드웨어 및/또는 회로들을 식별하거나 컴퓨터 코드를 작성할 수 있다.

따라서, 상술된 하드웨어 디바이스들 또는 프로그램 코드 명령들의 특별한 세트의 개시는, 본 발명을 어떻게 행하고 사용할지를 충분히 이해하는 데 필수적인 것으로 간주되지 않는다. 청구된 컴퓨터 구현 프로세스의 발명적 기능은, 상기의 설명에서 그리고 여러 프로세스 플로우들을 도시할 수도 있는 도면들과 연계하여 보다 상세히 설명되었다.

하나 이상의 예시적인 양태들에서, 상술된 기능들은 하드웨어, 소프트웨어, 펌웨어 또는 이들의 임의의 조합으로 구현될 수도 있다. 소프트웨어로 구현되면, 상기 기능들은 하나 이상의 명령들 또는 코드로서 컴퓨터 판독가능 매체 상에 저장되거나 또는 컴퓨터 판독가능 매체 상에서 전달될 수도 있다. 컴퓨터 판독가능 매체들은 한 장소에서 다른 장소로 컴퓨터 프로그램의 전송을 가능하게 하는 임의의 매체를 포함하여 컴퓨터 저장 매체들 및 통신 매체들 양자를 포함한다. 저장 매체는 컴퓨터에 의해 액세스될 수 있는 임의의 이용 가능한 매체일 수도 있다. 비제한적인 예로서, 이러한 컴퓨터 판독 가능한 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광학 디스크 스토리지, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스들, 또는 요구되는 프로그램 코드를 명령들 또는 데이터 구조들의 형태로 이송 또는 저장하기 위해 사용될 수 있으며 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다.

또한, 임의의 접속은 컴퓨터 판독 가능한 매체라고 적절히 칭해진다. 예를 들면, 소프트웨어가 동축 케이블, 광섬유 케이블, 연선, 디지털 가입자 회선, 또는 적외선, 무선, 및 마이크로파와 같은 무선 기술들을 사용하여 웹사이트, 서버, 또는 다른 원격 소스로부터 전송되면, 동축 케이블, 광섬유 케이블, 연선, 디지털 가입자 회선, 또는 적외선, 무선, 및 마이크로파와 같은 무선 기술들은 매체의 정의 내에 포함된다.

본원에서 사용된 디스크 (disk) 와 디스크 (disc) 는, 컴팩트 디스크 (CD), 레이저 디스크, 광학 디스크, 디지털 다기능 디스크 (DVD), 플로피디스크 및 블루레이 디스크를 포함하며, 여기서 디스크 (disk) 는 통상 자기적으로 데이터를 재생하고, 디스크 (disc) 는 레이저를 이용하여 광학적으로 데이터를 재생한다. 위의 조합들도 컴퓨터 판독가능 매체들의 범위 내에 포함되어야 한다.

선택된 양태들이 도해되고 상세히 설명되었지만, 하기의 특허청구범위에 의해 정의되는 본 발명의 취지와 범위로부터 벗어나지 않으면서 여러 대체예들 및 수정예들이 이루어질 수도 있음을 이해해야만 할 것이다.

Claims

휴대형 컴퓨팅 디바이스에 위치한 멀티코어 중앙 처리 유닛 (central processing unit, CPU)의 적어도 하나의 코어에 의해 제어되는 복수의 디바이스 리소스들을 갖는 휴대형 컴퓨팅 디바이스의 리소스들을 관리하는 방법으로서, 상기 방법은 프로세싱 시스템에 의해 수행되고, 상기 방법은:
상기 휴대형 컴퓨팅 디바이스의 하드웨어 혹은 소프트웨어 엘리먼트로부터, 상기 하드웨어 혹은 소프트웨어 엘리먼트를 나타내거나 혹은 모델링하는 인스턴스화되지 않은 (uninstantiated) 노드에 대한 노드 구조 데이터를 수신하는 단계로서, 상기 노드 구조 데이터는 상기 휴대형 컴퓨팅 디바이스 내에 포함되고 상기 노드의 일부인 각각의 상기 복수의 디바이스 리소스들에 대한 고유 명칭 (unique name) 을 포함하는, 상기 노드 구조 데이터를 수신하는 단계;
상기 휴대형 컴퓨팅 디바이스에 포함된 상기 복수의 디바이스 리소스들 사이의 하나 이상의 의존성들에 대해 상기 노드 구조 데이터를 리뷰하는 단계;
상기 인스턴스화되지 않은 노드에 대한 상기 하나 이상의 의존성들과 관련된 각각의 상기 복수의 디바이스 리소스들이 상기 컴퓨팅 디바이스에 대한 노드 프레임워크 내에 존재하는지 아닌지를 결정하는 단계로서, 상기 노드 프레임워크는 그래프에 의해 정의되고, 상기 그래프의 각각의 노드는 상기 휴대형 컴퓨팅 디바이스의 상기 CPU 에 의해 제어되는 하나 이상의 디바이스 리소스들을 나타내는, 상기 결정하는 단계;
상기 인스턴스화되지 않은 노드와 관련된 상기 복수의 디바이스 리소스들 각각이 상기 휴대형 컴퓨팅 디바이스 내부의 클라이언트로부터의 요청을 지원 (support) 하는 데 이용가능한지 아닌지를 결정하는 단계로서, 상기 클라이언트는 상기 휴대형 컴퓨팅 디바이스의 하드웨어 혹은 소프트웨어 엘리먼트를 포함하는, 상기 이용가능한지 아닌지를 결정하는 단계;
상기 하나 이상의 의존성들 각각에 대한 상기 복수의 디바이스 리소스들 각각이 존재하고 이용가능한 경우, 상기 멀티코어 CPU의 코어들 중 하나의 코어 상의 상기 인스턴스화되지 않은 노드를 인스턴스화하는 단계;
새로운 인스턴스화된 노드와 관련된 상기 복수의 디바이스 리소스들 중 하나에 대항하여 임계치 이벤트를 생성하는 단계;
상기 인스턴스화된 노드와 관련된 상기 복수의 디바이스 리소스들 각각이 대응하는 요청을 지원하기 위해 이용가능한지 여부를 결정하는 단계; 및
상기 인스턴스화된 노드와 관련된 상기 복수의 디바이스 리소스들 중 어느 하나가 대응하는 요청을 지원하기 위해 이용불가능한 경우, 상기 인스턴스화된 노드가 다른 디바이스 리소스들에 의해 사용되는 것을 금지하는 단계를 포함하고,
상기 임계치 이벤트를 생성하는 단계는,
상기 임계치 이벤트를 발생하기 위해 상기 복수의 디바이스 리소스들 중 다른 디바이스 리소스로부터 혹은 실행의 스레드(thread)로부터 하나 이상의 요청들을 수신하는 단계;
상기 임계치 이벤트와 관련된 복수의 조건들을 수신하는 단계;
상기 임계치 이벤트와 관련된 상기 복수의 조건들을 추적하는 하나 이상의 기능을 수신하는 단계;
상기 임계치 이벤트의 발생의 통지를 받을 각각의 상기 복수의 디바이스 리소스들에 대한 상기 고유 명칭을 수신하는 단계를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하는 방법..
제 1항에 있어서,
각각의 리소스는 제 2 소프트웨어 및 제 2 하드웨어 엘리먼트 중 적어도 하나를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하는 방법.
삭제
제 1항에 있어서,
상기 노드 구조 데이터를 수신하는 단계는, 상기 노드 프레임워크에서 하나 이상의 기능적인 리소스의 형성에 대한 플레이스홀더 (placeholder) 로서 기능하는 스터브 리소스를 형성하기 위한 데이터를 상기 휴대형 컴퓨팅 디바이스의 하드웨어 또는 소프트웨어 엘리먼트로부터 수신하는 단계를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하는 방법.
제 4항에 있어서,
상기 스터브 리소스를 기능적 리소스로 대체하기 위한 데이터를 수신하는 단계를 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하는 방법.
제 1항에 있어서,
상기 인스턴스화된 노드가 다른 디바이스 리소스들에 의해 사용되는 것을 금지하는 단계 후에, 상기 클라이언트 요청이 지연된 실행을 위해 억제가능한지 아닌지를 결정하는 단계를 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하는 방법.
제 6항에 있어서,
억제가능한 요청들의 실행을 지연시키기 위해 하나 이상의 조건들이 달성되었는지 아닌지를 결정하는 단계를 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하는 방법.
제 1항에 있어서,
상기 임계치 이벤트는 상기 휴대형 컴퓨팅 디바이스에 대한 온도 임계치를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하는 방법.
제 8항에 있어서,
임계치 이벤트와 관련된 상기 복수의 조건들은 상기 휴대형 컴퓨팅 디바이스의 복수의 온도들을 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하는 방법.
제 1항에 있어서,
상기 휴대형 컴퓨팅 디바이스는, 모바일 전화기, 개인 휴대 정보 단말기 (personal digital assistant), 페이저, 스마트폰, 내비게이션 디바이스, 및 무선 접속 또는 링크를 갖는 핸드헬드 컴퓨터 중 적어도 하나를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하는 방법.
멀티코어 중앙 처리 유닛 (central processing unit, CPU)의 적어도 하나의 코어에 의해 제어되는 복수의 디바이스 리소스들을 갖는 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템으로서,
상기 휴대형 컴퓨팅 디바이스에 위치한 상기 CPU 를 포함하고, 상기 CPU 의 적어도 하나의 코어는:
상기 휴대형 컴퓨팅 디바이스의 하드웨어 혹은 소프트웨어 엘리먼트로부터, 상기 하드웨어 혹은 소프트웨어 엘리먼트를 나타내거나 혹은 모델링하는 인스턴스화되지 않은 (uninstantiated) 노드에 대한 노드 구조 데이터를 수신하는 것으로서, 상기 노드 구조 데이터는 상기 휴대형 컴퓨팅 디바이스 내에 포함되고 상기 노드의 일부인 각각의 상기 복수의 디바이스 리소스들에 대한 고유 명칭을 포함하는, 상기 수신하는 것;
상기 휴대형 컴퓨팅 디바이스에 포함된 상기 복수의 디바이스 리소스들 사이의 하나 이상의 의존성들에 대해 상기 노드 구조 데이터를 리뷰하는 것;
상기 인스턴스화되지 않은 노드에 대한 상기 하나 이상의 의존성들과 관련된 각각의 상기 복수의 디바이스 리소스들이 상기 컴퓨팅 디바이스에 대한 노드 프레임워크 내에 존재하는지 아닌지를 결정하는 것으로서, 상기 노드 프레임워크는 그래프에 의해 정의되고, 상기 그래프의 각각의 노드는 상기 휴대형 컴퓨팅 디바이스의 상기 CPU에 의해 제어되는 하나 이상의 디바이스 리소스들을 나타내는, 상기 결정하는 것;
상기 인스턴스화되지 않은 노드와 관련된 상기 복수의 디바이스 리소스들 각각이 상기 휴대형 컴퓨팅 디바이스 내부의 클라이언트로부터의 요청을 지원하는 데 이용가능한지 아닌지를 결정하는 것으로서, 상기 클라이언트는 상기 휴대형 컴퓨팅 디바이스의 하드웨어 혹은 소프트웨어 엘리먼트를 포함하고,
상기 하나 이상의 의존성들 각각에 대한 상기 복수의 디바이스 리소스들 각각이 존재하고 이용가능한 경우, 상기 멀티코어 CPU의 코어들 중 하나의 코어 상의 인스턴스화되지 않은 노드를 인스턴스화하는 것;
새로운 인스턴스화된 노드와 관련된 상기 복수의 디바이스 리소스들 중 하나에 대항하여 임계치 이벤트를 생성하는 것;
상기 인스턴스화된 노드와 관련된 상기 복수의 디바이스 리소스들 각각이 대응하는 요청을 지원하기 위해 이용가능한지 여부를 결정하는 것; 및
상기 인스턴스화된 노드와 관련된 상기 복수의 디바이스 리소스들 중 어느 하나가 대응하는 요청을 지원하기 위해 이용불가능한 경우, 상기 인스턴스화된 노드가 다른 디바이스 리소스들에 의해 사용되는 것을 금지하는 것을 포함하고,
상기 임계치 이벤트를 생성하는 것은,
상기 임계치 이벤트를 발생하기 위해 상기 복수의 디바이스 리소스들 중 다른 디바이스 리소스로부터 혹은 실행의 스레드로부터 하나 이상의 요청들을 수신하는 것;
상기 임계치 이벤트와 관련된 복수의 조건들을 수신하는 것;
상기 임계치 이벤트와 관련된 상기 복수의 조건들을 추적하는 하나 이상의 기능을 수신하는 것;
상기 임계치 이벤트의 발생의 통지를 받을 각각의 상기 복수의 디바이스 리소스들에 대한 상기 고유 명칭을 수신하는 것을 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 11항에 있어서,
각각의 리소스는 제 2 소프트웨어 및 제 2 하드웨어 엘리먼트 중 적어도 하나를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
삭제
제 11항에 있어서,
상기 CPU 는:
상기 노드 프레임워크에서 적어도 하나의 기능적인 리소스의 형성에 대한 플레이스홀더로서 기능하는 스터브 리소스를 형성하기 위한 데이터를 수신하는 것을 하도록 더 동작가능한, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 14항에 있어서,
상기 CPU 는:
상기 스터브 리소스를 기능적 리소스로 대체하기 위한 데이터를 수신하는 것을 하도록 더 동작가능한, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 11항에 있어서,
상기 CPU 는:
상기 클라이언트 요청이 지연된 실행을 위해 억제가능한지 아닌지를 결정하는 것을 하도록 더 동작가능한, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 16항에 있어서,
상기 CPU 는:
억제가능한 요청들의 실행을 지연시키기 위해 하나 이상의 조건들이 달성되었는지 아닌지를 결정하는 것을 하도록 더 동작가능한, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 11항에 있어서,
상기 임계치 이벤트는 상기 휴대형 컴퓨팅 디바이스에 대한 온도 임계치를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 18항에 있어서,
상기 임계치 이벤트와 관련된 상기 복수의 조건들은 상기 휴대형 컴퓨팅 디바이스의 복수의 온도들을 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 11항에 있어서,
상기 휴대형 컴퓨팅 디바이스는, 모바일 전화기, 개인 휴대 정보 단말기, 페이저, 스마트폰, 내비게이션 디바이스, 및 무선 접속 또는 링크를 갖는 핸드헬드 컴퓨터 중 적어도 하나를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
휴대형 컴퓨팅 디바이스에 위치한 멀티코어 중앙 처리 유닛 (central processing unit, CPU)의 적어도 하나의 코어에 의해 제어되는 복수의 디바이스 리소스들을 갖는 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템으로서,
상기 컴퓨터 시스템은:
상기 휴대형 컴퓨팅 디바이스의 하드웨어 혹은 소프트웨어 엘리먼트로부터, 상기 하드웨어 혹은 소프트웨어 엘리먼트를 나타내거나 혹은 모델링하는 인스턴스화되지 않은 (uninstantiated) 노드에 대한 노드 구조 데이터를 수신하는 수단으로서, 상기 노드 구조 데이터는 상기 휴대형 컴퓨팅 디바이스 내에 포함되고 상기 노드의 일부인 각각의 상기 복수의 디바이스 리소스들에 대한 고유 명칭을 포함하는, 상기 수신하는 수단;
상기 휴대형 컴퓨팅 디바이스에 포함된 상기 복수의 디바이스 리소스들 사이의 하나 이상의 의존성들에 대해 상기 노드 구조 데이터를 리뷰하는 수단;
상기 인스턴스화되지 않은 노드에 대한 상기 하나 이상의 의존성들과 관련된 각각의 상기 복수의 디바이스 리소스들이 상기 컴퓨팅 디바이스에 대한 노드 프레임워크 내에 존재하는지 아닌지를 결정하는 수단으로서, 상기 노드 프레임워크는 그래프에 의해 정의되고, 상기 그래프의 각각의 노드는 상기 휴대형 컴퓨팅 디바이스의 상기 CPU 에 의해 제어되는 하나 이상의 디바이스 리소스들을 나타내는, 상기 결정하는 수단;
상기 인스턴스화되지 않은 노드와 관련된 상기 복수의 디바이스 리소스들 각각이 상기 휴대형 컴퓨팅 디바이스 내부의 클라이언트로부터의 요청을 지원하는 데 이용가능한지 아닌지를 결정하는 수단으로서, 상기 클라이언트는 상기 휴대형 컴퓨팅 디바이스의 하드웨어 혹은 소프트웨어 엘리먼트를 포함하는, 상기 이용가능한지 아닌지를 결정하는 수단;
상기 휴대형 컴퓨팅 디바이스에 위치한 상기 멀티코어 CPU 의 코어들 중 하나의 코어 상에서, 상기 하나 이상의 의존성들 각각에 대한 상기 복수의 디바이스 리소스들 각각이 존재하고 이용가능한 경우, 상기 휴대형 컴퓨팅 디바이스를 지원하기 위한 하나 이상의 대응하는 리소스들로 상기 인스턴스화되지 않은 노드를 인스턴스화하는 수단;
새로운 인스턴스화된 노드와 관련된 상기 복수의 디바이스 리소스들 중 하나에 대항하여 임계치 이벤트를 생성하는 수단;
상기 인스턴스화된 노드와 관련된 상기 복수의 디바이스 리소스들 각각이 대응하는 요청을 지원하기 위해 이용가능한지 여부를 결정하는 수단; 및
상기 인스턴스화된 노드와 관련된 상기 복수의 디바이스 리소스들 중 어느 하나가 대응하는 요청을 지원하기 위해 이용불가능한 경우, 상기 인스턴스화된 노드가 다른 디바이스 리소스들에 의해 사용되는 것을 금지하는 수단을 포함하고,
상기 임계치 이벤트를 생성하는 수단은,
상기 임계치 이벤트를 발생하기 위해 상기 복수의 디바이스 리소스들 중 다른 디바이스 리소스로부터 혹은 실행의 스레드(thread)로부터 하나 이상의 요청들을 수신하는 수단;
상기 임계치 이벤트와 관련된 복수의 조건들을 수신하는 수단;
상기 임계치 이벤트와 관련된 상기 복수의 조건들을 추적하는 하나 이상의 기능을 수신하는 수단;
상기 임계치 이벤트의 발생의 통지를 받을 각각의 상기 복수의 디바이스 리소스들에 대한 상기 고유 명칭을 수신하는 수단을 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 21항에 있어서,
각각의 리소스는 제 2 소프트웨어 및 제 2 하드웨어 엘리먼트 중 적어도 하나를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
삭제
제 21항에 있어서,
상기 노드 프레임워크에서 하나 이상의 기능적인 리소스의 형성을 위해 플레이스홀더로서 기능하는 스터브 리소스를 형성하기 위한 데이터를 수신하는 수단을 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 24항에 있어서,
상기 스터브 리소스를 기능적 리소스로 대체하기 위한 데이터를 수신하는 수단을 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 21항에 있어서,
상기 노드 프레임워크 내에서 관리되는 상기 클라이언트 요청이 지연된 실행을 위해 억제가능한지 아닌지를 결정하는 수단을 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 26항에 있어서,
억제가능한 요청들의 실행을 지연시키기 위해 하나 이상의 조건들이 달성되었는지 아닌지를 결정하는 수단을 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 21항에 있어서,
상기 휴대형 컴퓨팅 디바이스에 대한 온도 임계치를 포함하는 임계치 이벤트들을, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 28항에 있어서,
상기 임계치 이벤트와 관련된 상기 복수의 조건들은 상기 휴대형 컴퓨팅 디바이스의 복수의 온도들을 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
제 21항에 있어서,
상기 휴대형 컴퓨팅 디바이스는, 모바일 전화기, 개인 휴대 정보 단말기, 페이저, 스마트폰, 내비게이션 디바이스, 및 무선 접속 또는 링크를 갖는 핸드헬드 컴퓨터 중 적어도 하나를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
컴퓨터 판독가능 프로그램 코드가 수록된 컴퓨터 판독가능 저장매체로서,
상기 컴퓨터 판독가능 프로그램 코드는, 휴대형 컴퓨팅 디바이스에 위치한 멀티코어 중앙 처리 유닛 (central processing unit, CPU)의 적어도 하나의 코어에 의해 제어되는 복수의 디바이스 리소스들을 갖는 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법을 구현하도록 실행되고,
상기 방법은:
상기 휴대형 컴퓨팅 디바이스의 하드웨어 혹은 소프트웨어 엘리먼트로부터, 상기 하드웨어 혹은 소프트웨어 엘리먼트를 나타내거나 혹은 모델링하는 인스턴스화되지 않은 (uninstantiated) 노드에 대한 노드 구조 데이터를 수신하는 단계로서, 상기 노드 구조 데이터는 상기 휴대형 컴퓨팅 디바이스 내에 포함되고 상기 노드의 일부인 각각의 상기 복수의 디바이스 리소스들에 대한 고유 명칭을 포함하는, 상기 수신하는 단계;
상기 휴대형 컴퓨팅 디바이스에 포함된 상기 복수의 디바이스 리소스들 사이의 하나 이상의 의존성들에 대해 상기 노드 구조 데이터를 리뷰하는 단계;
상기 인스턴스화되지 않은 노드에 대한 상기 하나 이상의 의존성들과 관련된 각각의 상기 복수의 디바이스 리소스들이 상기 컴퓨팅 디바이스에 대한 노드 프레임워크 내에 존재하는지 아닌지를 결정하는 단계로서, 상기 노드 프레임워크는 그래프에 의해 정의되고, 상기 그래프의 각각의 노드는 상기 휴대형 컴퓨팅 디바이스의 상기 CPU 에 의해 제어되는 하나 이상의 디바이스 리소스들을 나타내는, 상기 결정하는 단계;
상기 인스턴스화되지 않은 노드와 관련된 상기 복수의 디바이스 리소스들 각각이 상기 휴대형 컴퓨팅 디바이스 내부의 클라이언트로부터의 요청을 지원하는 데 이용가능한지 아닌지를 결정하는 단계로서, 상기 클라이언트는 상기 휴대형 컴퓨팅 디바이스의 하드웨어 혹은 소프트웨어 엘리먼트를 포함하는, 상기 이용가능한지 아닌지를 결정하는 단계;
상기 하나 이상의 의존성들 각각에 대한 상기 복수의 디바이스 리소스들 각각이 존재하고 이용가능한 경우, 상기 멀티코어 CPU의 코어들 중 하나의 코어 상의 상기 인스턴스화되지 않은 노드를 인스턴스화하는 단계;
새로운 인스턴스화된 노드와 관련된 상기 복수의 디바이스 리소스들 중 하나에 대항하여 임계치 이벤트를 생성하는 단계;
상기 인스턴스화된 노드와 관련된 상기 복수의 디바이스 리소스들 각각이 대응하는 요청을 지원하기 위해 이용가능한지 여부를 결정하는 단계; 및
상기 인스턴스화된 노드와 관련된 상기 복수의 디바이스 리소스들 중 어느 하나가 대응하는 요청을 지원하기 위해 이용불가능한 경우, 상기 인스턴스화된 노드가 다른 디바이스 리소스들에 의해 사용되는 것을 금지하는 단계를 포함하고,
상기 임계치 이벤트를 생성하는 단계는,
상기 임계치 이벤트를 발생하기 위해 상기 복수의 디바이스 리소스들 중 다른 디바이스 리소스로부터 혹은 실행의 스레드(thread)로부터 하나 이상의 요청들을 수신하는 단계;
상기 임계치 이벤트와 관련된 복수의 조건들을 수신하는 단계;
상기 임계치 이벤트와 관련된 상기 복수의 조건들을 추적하는 하나 이상의 기능을 수신하는 단계;
상기 임계치 이벤트의 발생의 통지를 받을 각각의 상기 복수의 디바이스 리소스들에 대한 상기 고유 명칭을 수신하는 단계를 포함하는, 컴퓨터 판독가능 프로그램 코드가 수록된 컴퓨터 판독가능 저장매체.
제 31항에 있어서,
각각의 리소스는 제 2 소프트웨어 및 제 2 하드웨어 엘리먼트 중 적어도 하나를 포함하는, 컴퓨터 판독가능 프로그램 코드가 수록된 컴퓨터 판독가능 저장매체.
삭제
제 31항에 있어서,
상기 방법을 구현하는 상기 프로그램 코드는,
상기 휴대형 컴퓨팅 디바이스의 하드웨어 혹은 소프트웨어 엘리먼트로부터, 상기 노드 프레임워크에서 하나 이상의 기능적인 리소스의 형성을 위한 플레이스홀더로서 기능하는 스터브 리소스를 형성하기 위한 데이터를 수신하는 단계를 더 포함하는, 컴퓨터 판독가능 프로그램 코드가 수록된 컴퓨터 판독가능 저장매체.
제 34항에 있어서,
상기 방법을 구현하는 상기 프로그램 코드는,
상기 스터브 리소스를 기능적 리소스로 대체하기 위한 데이터를 수신하는 단계를 더 포함하는, 컴퓨터 판독가능 프로그램 코드가 수록된 컴퓨터 판독가능 저장매체.
제 31항에 있어서,
상기 방법을 구현하는 상기 프로그램 코드는,
상기 클라이언트 요청이 지연된 실행을 위해 억제가능한지 아닌지를 결정하는 단계를 더 포함하는, 컴퓨터 판독가능 프로그램 코드가 수록된 컴퓨터 판독가능 저장매체.
제 36항에 있어서,
상기 방법을 구현하는 상기 프로그램 코드는,
억제가능한 요청들의 실행을 지연시키기 위해 상기 복수의 조건들 중 하나 이상의 조건들이 달성되었는지 아닌지를 결정하는 단계를 더 포함하는, 컴퓨터 판독가능 프로그램 코드가 수록된 컴퓨터 판독가능 저장매체.
제 31항에 있어서,
상기 방법을 구현하는 상기 프로그램 코드는,
하나 이상의 임계치 이벤트는 상기 휴대형 컴퓨팅 디바이스에 대한 온도 임계치를 포함하는, 컴퓨터 판독가능 프로그램 코드가 수록된 컴퓨터 판독가능 저장매체.
제 38항에 있어서,
임계치 이벤트와 관계된 복수의 조건들은 상기 휴대형 컴퓨팅 디바이스의 복수의 온도들을 포함하는, 컴퓨터 판독가능 프로그램 코드가 수록된 컴퓨터 판독가능 저장매체.
제 31항에 있어서,
상기 휴대형 컴퓨팅 디바이스는, 모바일 전화기, 개인 휴대 정보 단말기, 페이저, 스마트폰, 내비게이션 디바이스, 및 무선 접속 또는 링크를 갖는 핸드헬드 컴퓨터 중 적어도 하나를 포함하는, 컴퓨터 판독가능 프로그램 코드가 수록된 컴퓨터 판독가능 저장매체.