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

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

Info

Publication number
KR20130084659A
KR20130084659A KR1020137009467A KR20137009467A KR20130084659A KR 20130084659 A KR20130084659 A KR 20130084659A KR 1020137009467 A KR1020137009467 A KR 1020137009467A KR 20137009467 A KR20137009467 A KR 20137009467A KR 20130084659 A KR20130084659 A KR 20130084659A
Authority
KR
South Korea
Prior art keywords
node
resource
resources
structure data
computing device
Prior art date
Application number
KR1020137009467A
Other languages
English (en)
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 KR20130084659A publication Critical patent/KR20130084659A/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/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
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • 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
    • 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/50—Allocation of resources, e.g. of the central processing unit [CPU]

Landscapes

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

Abstract

휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법 및 시스템이 개시된다. 이러한 방법은 노드를 형성하기 위한 노드 구조 데이터를 수신하는 단계를 포함하는데, 여기서 노드 구조 데이터는 노드의 각 자원에게 지정된 고유 명칭을 포함한다. 하나의 노드는 적어도 하나의 리소스를 가지며 노드는 다중 리소스들을 가질 수도 있다. 각 리소스는 하드웨어 또는 소프트웨어 엘리먼트일 수도 있다. 이러한 시스템은 노드 아키텍쳐 내의 기존 노드들 간의 통신들을 핸들링하는 프레임워크 관리자를 포함한다. 또한, 프레임워크 관리자는 각 리소스의 활동성을 그 고유 명칭을 이용하여 로깅 (log) 한다. 프레임워크 관리자는 이러한 로깅된 활동성을 출력 디바이스, 예컨대 프린터 또는 디스플레이 스크린으로 전송할 수도 있다. 이러한 방법 및 시스템은 새로운 하드웨어 또는 소프트웨어 엘리먼트 (또는 양쪽 모두) 가 휴대형 컴퓨팅 디바이스에 추가될 때 맞춤화된 API 들을 감소시키거나 이에 대한 필요성을 제거하도록 도울 수도 있다.

Description

휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 시스템 및 방법{SYSTEM AND METHOD FOR MANAGING RESOURCES OF A PORTABLE COMPUTING DEVICE}
휴대형 컴퓨팅 디바이스들 (portable computing devices; PCDs) 은 개인적인 그리고 전문가적인 레벨들에서 사람들에 대한 개인적 필수품들이 되어가고 있다. 이러한 디바이스들은 셀룰러 전화기들, 개인 휴대 정보 단말기들 (portable digital assistants; PDAs), 휴대형 게임 콘솔들, 팜탑 컴퓨터들, 및 다른 휴대형 전자 디바이스들을 포함할 수도 있다. 이러한 디바이스들의 각각은 주된 기능을 포함할 수도 있다. 예를 들어, 셀룰러 전화기는 일반적으로 전화 호들을 수신하고 송신하는 주된 기능을 가진다.
이러한 디바이스들의 주된 기능에 추가하여, 많은 것들이 부수적 기능들을 포함한다. 예를 들어, 셀룰러 전화기는 위에서 설명된 바와 같이 셀룰러 전화 호들을 생성하는 주된 기능, 및 스틸 카메라, 비디오 카메라, 글로벌 측위 시스템 (GPS) 내비게이션, 웹 브라우징, 이메일의 전송 및 수신, 텍스트 메시지들의 전송 및 수신, 푸시-투-토크 능력들 등의 부수적 기능들을 포함할 수도 있다. 이러한 디바이스의 기능성이 증가함에 따라서, 이러한 기능성을 지원하기 위하여 요구되는 컴퓨팅 또는 프로세싱 능력 역시 증가한다. 더 나아가, 컴퓨팅 능력이 증가함에 따라서, 컴퓨팅 능력을 제공하는 프로세서, 또는 프로세서들을 효과적으로 관리할 더 큰 필요성이 존재한다.
과거에는, 하드웨어 또는 소프트웨어 (또는 양자의) 에 의하여 지원되는 각각의 부수적 기능이 셀룰러 전화기와 같은 디바이스에 도입될 때에, 특정 애플리케이션 프로그래밍 인터페이스 (application programming interface; API) 가 각각의 부수적 기능에 대하여 도입되었다. 예를 들어, 비디오 카메라에 대한 별개의 API 및 GPS 내비게이션 애플리케이션 소프트웨어에 대한 별개의 API가 존재할 수도 있다. 각각의 API 는 일반적으로 자신의 동작들을 독립적으로 로깅하며, 그리고 각각의 API 는, 새로운 부수적 기능의 도입 이전에 이미 존재했던 셀룰러 전화기의 기존의 하드웨어 또는 소프트웨어를 상호 참조할 필요가 있을 수도 있는 그 자신의 데이터 구조를 가진다.
각각의 부수적 기능에 대하여 별개의 API들을 도입하는 것은 상이한 하드웨어 또는 소프트웨어 엘리먼트들에 대한 상호 참조 때문에 매우 귀찮은 일이며 시간을 많이 소비한다. 셀룰러 전화기의 기초적 기능들을 지원하는 각각의 하드웨어 또는 소프트웨어 엘리먼트에는 셀룰러 전화기의 원 장비 제조사 (original equipment manufacturer; OEM) 및/또는 셀룰러 전화기의 기초적 기능들을 지원하는 내재하는 전자 기기의 OEM 에 의하여 확립된 전문 용어들이 제공되었을 수도 있다. 소프트웨어 또는 하드웨어 (또는 양쪽 모두) 와 연관된 새로운 피쳐들 또는 기능들의 로깅 및 디버깅은 오랫동안 이러한 휴대형 컴퓨팅 디바이스 기술 분야의 당업자들에게 새로운 제품들 또는 피쳐들 (또는 양쪽 모두) 를 제공하는 데 있어서 커다란 문제점으로 인식되어 왔다.
필요한 것은 원 장비 제조사들 (OEMs) 에 의하여 제작된 시스템들에 추가된 새로운 소프트웨어 또는 하드웨어 (또는 양쪽 모두) 에 의하여 지원되는 새로운 피쳐들 또는 기능들을 도입하는 것과 연관된 문제점들을 극복할 수도 있는 시스템 및 방법이다.
휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법 및 시스템이 개시된다. 이러한 방법은 노드를 형성하기 위한 노드 구조 데이터 (node structure data) 를 수신하는 단계를 포함하는데, 여기서 노드 구조 데이터는 노드의 각 리소스에게 지정된 고유 명칭을 포함한다. 노드는 적어도 하나의 리소스를 가지며, 다중 리소스들을 가질 수도 있다. 각각의 리소스는 하드웨어 또는 소프트웨어 엘리먼트일 수도 있다. 이러한 시스템은 노드 아키텍쳐 내의 기존의 노드들 간의 통신들을 핸들링하는 프레임워크 관리자를 포함한다. 또한, 프레임워크 관리자는 각각의 리소스의 활동성을 그것의 개별 고유 명칭을 이용하여 로깅 (log) 한다. 프레임워크 관리자는 이러한 로깅된 활동성을 메모리, 내장형 파일시스템과 같은 비휘발성 스토리지, 또는 프린터 또는 디스플레이 스크린과 같은 출력 디바이스로 전송할 수도 있다. 이러한 방법 및 시스템은 새로운 하드웨어 또는 소프트웨어 엘리먼트 (또는 양쪽 모두) 가 휴대형 컴퓨팅 디바이스에 추가될 때 맞춤화된 API 에 대한 필요성을 감소시키거나 제거하도록 도울 수도 있다.
제 1 예시적인 측면에 따르면, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법은 노드를 형성하기 위한 노드 구조 데이터를 수신하는 단계를 포함하는데, 여기서 노드 구조 데이터는 고유 명칭을 포함한다. 더 나아가, 이러한 방법은 노드 구조 데이터를 하나 이상의 종속성들에 대하여 리뷰하는 단계 및 종속성과 연관된 각 리소스가 노드 프레임워크 내에 존재하는지를 결정하는 단계를 포함한다. 종속성과 연관된 리소스가 존재하지 않는다면, 노드 구조 데이터는 임시 스토리지에 저장된다. 각 종속성에 대한 각 리소스가 존재한다면, 노드 및 그 노드의 하나 이상의 대응하는 리소스들이 생성된다. 노드가 생성되면, 통신들을 처리하기 위한 상태 대기 (state ready) 의 노드의 대응하는 고유 명칭들을 이용하여 노드 프레임워크 내에서 노드가 공개 (publish) 된다.
다른 예시적인 측면에 따르면, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템은 노드를 형성하기 위한 노드 구조 데이터를 수신하도록 동작가능한 프로세서를 포함하는데, 여기서 노드 구조 데이터는 해당 노드의 일부인 각 리소스에 대한 고유 명칭을 포함한다. 또한, 프로세서는 노드 구조 데이터를 하나 이상의 종속성들에 대하여 리뷰하도록 동작가능하고, 프로세서는 종속성과 연관된 각 노드가 노드 프레임워크 내에 존재하는지를 결정하도록 동작가능하다. 종속성과 연관된 리소스가 존재하지 않는다면, 프로세서는 노드 구조 데이터를 임시 스토리지에 저장하도록 동작가능하다. 각 종속성에 대한 각 리소스가 존재한다면, 프로세서는 노드 및 해당 노드의 하나 이상의 대응하는 리소스들을 생성하도록 동작가능하다. 노드가 생성되면, 프로세서는 통신들을 처리하기 위한 상태 대기의 노드의 하나 이상의 리소스들에 대응하는 하나 이상의 고유 명칭들을 이용하여 노드 프레임워크 내에서 노드를 공개하도록 동작가능하다.
다른 예시적인 측면에 따르면, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템은 노드를 형성하기 위한 노드 구조 데이터를 수신하는 수단을 포함하는데, 여기서 노드 구조 데이터는 노드의 일부인 각 리소스에 대한 고유 명칭을 포함한다. 더 나아가, 컴퓨터 시스템은 노드 구조 데이터를 하나 이상의 종속성들에 대하여 리뷰하는 수단 및 종속성과 연관된 각 리소스가 노드 프레임워크 내에 존재하는지를 결정하는 수단을 가진다. 더 나아가, 컴퓨터 시스템은 종속성과 연관된 리소스가 존재하지 않는다면, 노드 구조 데이터를 임시 스토리지에 저장하는 수단을 포함한다. 또한, 컴퓨터 시스템은 각 종속성에 대한 각 리소스가 존재한다면, 노드 및 해당 노드의 하나 이상의 대응하는 리소스들을 생성하는 수단을 가진다. 더 나아가, 컴퓨터 시스템은 노드가 생성되면, 통신들을 처리하기 위한 상태 대기의 노드의 하나 이상의 리소스들에 대응하는 하나 이상의 고유 명칭들을 이용하여 노드 프레임워크 내에서 해당 노드를 공개하는 수단을 가진다.
다른 양태에 따르면, 컴퓨터 프로그램 제품은 컴퓨터 판독가능 프로그램 코드를 포함하는 컴퓨터 이용가능 매체를 포함하는데, 여기서 프로그램 코드는 실행되어 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법을 구현하도록 구성된다. 이러한 코드에 의하여 구현되는 방법은 노드를 형성하기 위한 노드 구조 데이터를 수신하는 단계를 포함하는데, 여기서 노드 구조 데이터는 해당 노드의 일부인 각 리소스에 대한 고유 명칭을 가진다. 또한, 이러한 방법은 노드 구조 데이터를 하나 이상의 종속성들에 대하여 리뷰하는 단계 및 종속성과 연관된 각 리소스가 노드 프레임워크 내에 존재하는지를 결정하는 단계를 포함한다. 종속성과 연관된 리소스가 존재하지 않는다면, 이러한 방법은 노드 구조 데이터를 임시 스토리지에 저장한다. 각 종속성에 대한 각 리소스가 존재한다면, 이러한 프로세스는 노드 및 해당 노드의 하나 이상의 대응하는 리소스들을 생성한다. 노드가 생성되면, 이러한 프로세스는 통신들을 처리하기 위한 상태 대기의 해당 노드의 하나 이상의 리소스들에 대응하는 하나 이상의 고유 명칭들을 이용하여 노드 프레임워크 내에서 해당 노드를 공개한다.
도면들에서, 그렇지 않다고 표시되지 않는 한 유사한 참조 번호들은 다양한 도면들 전체에서 유사한 부분들을 지칭한다. "102A" 또는 "102B" 와 같은 문자 지시자들이 있는 참조 번호들에 대해서는, 문자 지시자들이 동일한 도면 내에 존재하는 두 개의 유사한 부분들 또는 엘리먼트들을 구별할 수도 있다. 참조 번호들에 대한 문자 지시자들은 참조 번호가 모든 도면들 내의 동일한 참조 번호를 가지는 모든 부분들을 망라하는 것이 의도되면 생략될 수도 있다.
도 1 은 닫힌 포지션에 있는 휴대형 컴퓨팅 디바이스 (PCD) 의 제 1 양태의 정면도이다;
도 2 는 열린 포지션에 있는 휴대형 컴퓨팅 디바이스 (PCD) 의 제 1 양태의 정면도이다;
도 3 은 PCD의 제 2 양태의 블록도이다;
도 4 는 프로세싱 시스템의 블록도이다;
도 5 는 도 1 의 휴대형 컴퓨팅 디바이스의 리소스들을 관리하는 시스템에 대한 소프트웨어 아키텍처의 제 1 양태의 도면이다;
도 6 은 도 1 의 PCD의 리소스들을 관리하는 시스템에 대한 소프트웨어 아키텍처의 제 2 양태의 도면이다;
도 7a 는 PCD의 리소스(들)을 관리하기 위한 소프트웨어 아키텍처를 생성하기 위한 방법을 예시하는 흐름도이다;
도 7b 는 PCD의 리소스(들)을 관리하기 위한 소프트웨어 아키텍처를 생성하기 위한 방법을 예시하는 도 7a 의 연속 흐름도이다;
도 8 은 PCD 내의 소프트웨어 아키텍처 내의 노드 구조 데이터를 수신하기 위한 도 7a 및 도 7b 의 서브방법 또는 루틴을 예시하는 흐름도이다;
도 9 는 PCD 에 대한 소프트웨어 아키텍처 내에 노드를 생성하기 위한 도 7a 및 도 7b 의 서브방법 또는 루틴을 예시하는 흐름도이다;
도 10 은 PCD에 대한 소프트웨어 아키텍처에 의하여 유지될 수도 있는 예시적인 명칭 테이블에 대한 데이터 구조의 도면이다;
도 11 은 PCD에 대한 소프트웨어 아키텍처 내에 리소스의 에일리어스 (alias) 를 생성하기 위한 방법을 예시하는 흐름도이다;
도 12 는 PCD의 소프트웨어 아키텍처 내에 클라이언트를 생성하기 위한 도 9 의 서브방법 또는 루틴을 예시하는 흐름도이다;
도 13 은 PCD에 대한 소프트웨어 아키텍처 내의 리소스에 대한 클라이언트 요청을 생성하기 위한 방법을 예시하는 흐름도이다;
도 14 는 PCD의 리소스에 대한 등시성 (isochronous) 클라이언트 요청 내에서 요청되는 작업을 예시하는 도면이다;
도 15 는 PCD에 대한 소프트웨어 아키텍처 내의 리소스에 대한 등시성 클라이언트 요청을 생성하기 위한 도 9 의 서브방법 또는 루틴을 예시하는 흐름도이다.
단어 "예시적인" 은 본 명세서에서 "일 예, 실례, 또는 예시로서 기능한다" 는 것을 의미하도록 이용된다. 본 명세서에서 "예시적인" 것으로 기술되는 임의의 양태는 반드시 다른 양태들에 비하여 바람직하거나 이점을 가지는 것으로 이해될 필요가 없다.
이러한 발명을 실시하기 위한 구체적인 내용에서, 용어 "애플리케이션" 도 역시 실행가능한 콘텐츠를 가지는 파일들, 예컨대: 오브젝트 코드, 스크립트들, 바이트 코드, 마크업 언어 파일들, 및 패치들을 포함할 수도 있다. 또한, 본 명세서에서 지칭되는 "애플리케이션" 도 역시 성질상 실행가능하지 않은 파일들, 예컨대 열릴 필요가 있을 수도 있는 문서들 또는 액세스될 필요가 있는 다른 데이터 파일들을 포함할 수도 있다.
또한, 용어 "콘텐츠" 는 실행가능한 콘텐츠, 예컨대: 오브젝트 코드, 스크립트들, 바이트 코드, 마크업 언어 파일들, 및 패치들을 가지는 파일들을 포함할 수도 있다. 또한, 본 명세서에서 지칭되는 "콘텐츠" 도 역시 성질상 실행가능하지 않은 파일들, 예컨대 열릴 필요가 있을 수도 있는 문서들 또는 액세스될 필요가 있는 다른 데이터 파일들을 포함할 수도 있다.
본 명세서에서 사용될 때, 용어들 "컴포넌트", "데이터베이스", "모듈", "시스템", 및 기타 등등은 하드웨어, 펌웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어, 또는 실행 중인 소프트웨어 중 하나인 컴퓨터-관련 엔티티를 지칭하도록 의도된다. 예를 들어, 컴포넌트는 프로세서 상에서 실시 중인 프로세스, 프로세서, 오브젝트, 실행가능한 개체 (executable), 실행의 스레드, 프로그램, 및/또는 컴퓨터일 수도 있는데 이것들일 것으로 한정되는 것은 아니다. 일 예로서, 컴퓨팅 디바이스 상에서 실시 중인 애플리케이션 및 그 컴퓨팅 디바이스 모두가 컴포넌트일 수도 있다. 하나 이상의 컴포넌트들은 프로세스 및/또는 실행의 스레드 내에 상주할 수도 있고, 그리고 컴포넌트는 하나의 컴퓨터 상에 국부화되거나 그리고/또는 두 개 이상의 컴퓨터들 사이에 분산될 수도 있다. 또한, 이러한 컴포넌트들은 저장된 다양한 데이터 구조들을 가지는 다양한 컴퓨터 판독가능 매체들로부터 실행할 수도 있다. 컴포넌트들은 로컬 및/또는 원격 프로세스들을 통하여, 예컨대 하나 이상의 데이터 패킷들 (예를 들어, 로컬 시스템, 분산 시스템 내의 다른 컴포넌트, 및/또는 신호를 통해서 인터넷과 같은 네트워크를 통과하여 다른 시스템들과 상호작용하는 하나의 컴포넌트로부터의 데이터) 을 가지는 신호에 따라서 통신할 수도 있다.
이러한 발명을 실시하기 위한 구체적인 내용에서, 용어들 "통신 디바이스", "무선 디바이스", "무선 전화기", "무선 통신 디바이스", 및 "무선 핸드셋" 은 상호 교환 가능하도록 이용된다. 제 3 세대 ("3G") 무선 기술이 도래함에 따라서, 더 큰 대역폭 이용가능성이 더 많은 휴대형 컴퓨팅 디바이스들에게 무선 성능들의 능력들의 더 큰 다양성을 이네이블해 왔다. 그러므로, 휴대형 컴퓨팅 디바이스는 셀룰러 전화기, 페이저 (pager), 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) 는 복수 개의 표시자 라이트들 (116) 및 스피커 (118) 를 포함할 수도 있다. 각각의 표시자 라이트 (116) 는 발광 다이오드 (LED) 일 수도 있다.
특정한 양태에서는, 도 2 에 도시된 바와 같이, 상부 하우징부 (104) 는 하부 하우징부 (106) 에 대하여 상대적으로 이동가능하다. 구체적으로 설명하면, 상부 하우징부 (104) 는 하부 하우징부 (106) 에 대하여 상대적으로 슬라이드될 수 있을 수도 있다. 도 2 에서 도시된 바와 같이, 하부 하우징부 (106) 는 멀티-버튼 키보드 (120) 를 포함할 수도 있다. 특정한 양태에서는, 멀티-버튼 키보드 (120) 는 표준 QWERTY 키보드일 수도 있다. 멀티-버튼 키보드 (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 에서 도시된 바와 같이, 범용 시리얼 버스 (universal serial bus; USB) 제어기 (340) 가 멀티코어 CPU (402) 에 커플링된다. 또한, USB 포트 (342) 는 USB 제어기 (340) 에 커플링된다. 또한, 메모리 (404) 및 가입자 식별 모듈 (subscriber identity module; SIM) 카드 (346) 가 멀티코어 CPU (402) 에 커플링된다. 더 나아가, 도 3 에서 도시된 바와 같이, 디지털 카메라 (348) 가 멀티코어 CPU (402) 에 커플링된다. 예시적인 양태에서는, 디지털 카메라 (348) 는 전하 결합 소자 (charge-coupled device; CCD) 카메라 또는 상보형 금속 산화물 반도체 (complementary metal-oxide semiconductor; CMOS) 카메라이다.
도 3 에서 더욱 도시된 바와 같이, 스테레오 오디오 코덱 (350) 이 멀티코어 CPU (402) 에 커플링될 수도 있다. 더욱이, 오디오 증폭기 (352) 가 스테레오 오디오 코덱 (350) 에 커플링된다. 예시적인 양태에서는, 제 1 스테레오 스피커 (354) 및 제 2 스테레오 스피커 (356) 가 오디오 증폭기 (352) 에 커플링된다. 도 3 은 마이크로폰 증폭기 (358) 가 스테레오 오디오 코덱 (350) 에 커플링될 수 있다는 것을 도시한다. 추가적으로, 마이크로폰 (360) 은 마이크로폰 증폭기 (358) 에 커플링될 수도 있다. 특정한 양태에서는, 주파수 변조 (frequency modulation; FM) 라디오 튜너 (362) 가 스테레오 오디오 코덱 (350) 에 커플링될 수도 있다. 또한, FM 안테나 (364) 가 FM 라디오 튜너 (362) 에 커플링된다. 더 나아가, 스테레오 헤드폰들 (366) 이 스테레오 오디오 코덱 (350) 에 커플링될 수도 있다.
더 나아가, 도 3 은 무선 주파수 (RF) 송수신기 (368) 가 멀티코어 CPU (402) 에 커플링될 수도 있다는 것을 표시한다. RF 스위치 (370) 가 RF 송수신기 (368) 및 RF 안테나 (372) 에 커플링될 수도 있다. 도 3 에서 도시된 바와 같이, 키패드 (374) 가 멀티코어 CPU (402) 에 커플링될 수도 있다. 또한, 마이크로폰이 있는 모노 헤드셋 (376) 이 멀티코어 CPU (402) 에 커플링될 수도 있다. 더 나아가, 진동기 디바이스 (378) 가 멀티코어 CPU (402) 에 커플링될 수도 있다. 또한, 도 3 은 전원 (380) 이 온칩 시스템 (322) 에 커플링될 수도 있다는 것을 도시한다. 특정한 양태에서는, 전원 (380) 은 전력을 요구하는 PCD (100) 의 다양한 컴포넌트들로 전력을 공급하는 직류 전류 (DC) 전원이다. 더 나아가, 특정한 양태에서는, 전원은 AC 전력 소스에 연결된 교류 전류 (AC)-DC 변압기로부터 유도된 충전 가능한 DC 배터리 또는 DC 전원이다.
더 나아가, 도 3 은 PCD (100) 가 데이터 네트워크, 예를 들어, 근거리 네크워크, 개인 영역 네트워크, 또는 임의의 다른 네트워크에 액세스하는데 이용될 수도 있는 네트워크 카드 (388) 를 또한 포함할 수도 있다는 것을 표시한다. 네트워크 카드 (388) 는 블루투스 네트워크 카드, WiFi 네트워크 카드, 개인 영역 네트워크 (personal area network; PAN) 카드, 개인 영역 네트워크 초저전력 기술 (personal area network ultra-low-power technology; PeANUT) 네트워크 카드, 또는 당업계에 주지된 임의의 다른 네트워크 카드일 수도 있다. 더 나아가, 네트워크 카드 (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), 또는 이들의 조합은 중앙 처리 유닛 (402) 내의 데이터를 샘플링하기 위하여 본 명세서에서 설명되는 방법 단계들 중 하나 이상을 실행하는 수단으로서 기능할 수도 있다.
도 4 를 참조하면, 프로세싱 시스템이 도시되고 총칭적으로 참조 번호 400 이 부여된다. 특정한 양태에서는, 프로세싱 시스템 (400) 은 도 3 과 연계하여 위에서 설명된 PCD (100) 내에 통합될 수도 있다. 도시된 바와 같이, 프로세싱 시스템 (400) 은 멀티코어 중앙 처리 유닛 (central processing unit; 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 실시 큐 (run queue; 424), 제 2 실시 큐 (426), 및 제 N 실시 큐 (428) 를 포함할 수도 있다. 메모리 (404) 는 또한 그 상에 저장된 제 1 애플리케이션 (430), 제 2 애플리케이션 (432), 및 제 N 애플리케이션 (434) 을 포함할 수도 있다.
특정한 양태에서는, 애플리케이션들 (430, 432, 434) 은 하나 이상의 태스크들 (436) 을 멀티코어 CPU (402) 내의 코어들 (410, 412, 414) 에서 처리되도록 운영 체제 (420) 로 전송할 수도 있다. 태스크들 (436) 은 단일 태스크들, 스레드들, 또는 이들의 조합으로서 처리되고 실행될 수도 있다. 더 나아가, 스케줄러 (422) 는 태스크들, 스레드들, 또는 이들의 조합을 멀티코어 CPU (402) 내에서의 실행을 위하여 스케줄링할 수도 있다. 추가적으로, 스케줄러 (422) 는 태스크들, 스레드들, 또는 이들의 조합을 실시 큐들 (424, 426, 428) 내에 배치할 수도 있다. 코어들 (410, 412, 414) 은 태스크들, 스레드들, 또는 이들의 조합을 실시 큐들 (424, 426, 428) 로부터, 예를 들어, 코어들 (410, 412, 414) 에서의 이러한 태스크들 및 스레드들의 처리 또는 실행을 위하여 운영 체제 (420) 에 의하여 지시되는 바와 같이 취출할 수도 있다.
또한, 도 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 는 중앙 처리 유닛 (402) (또한 총칭적으로 제 1 하드웨어 엘리먼트 (하드웨어 엘리먼트 #1) 이라고도 지칭됨); CPU (402) 에 대한 클록 (442) (또한 총칭적으로 제 2 하드웨어 엘리먼트 (하드웨어 엘리먼트 #2) 라고도 지칭됨); 버스 중재기 또는 스케줄러 (422) (또한 총칭적으로 제 3 하드웨어 엘리먼트 (하드웨어 엘리먼트 #3) 라고도 지칭됨); 버스 프로그램 A (444A) (또한 총칭적으로 제 1 소프트웨어 엘리먼트 (소프트웨어 엘리먼트 #1) 라고도 지칭됨); 버스 프로그램 B (444B) (또한 총칭적으로 제 2 소프트웨어 엘리먼트 (소프트웨어 엘리먼트 #2) 라고도 지칭됨); 클록 프로그램 AHB (또한 총칭적으로 제 3 소프트웨어 엘리먼트 (소프트웨어 엘리먼트 #3) 라고도 지칭됨); 소프트웨어 엘리먼트에 의하여 모니터링되는 액션 또는 기능 (일반적으로 키프레스 (448) 라고 표시됨); 및 소프트웨어 엘리먼트 또는 소프트웨어 엘리먼트 또는 양쪽 모두를 포함하는 레거시 엘리먼트 (450) 와 같지만 이에 한정되는 것은 아닌 복수 개의 하드웨어 또는 소프트웨어 엘리먼트들에 커플링되는 아키텍처 또는 프레임워크 관리자 (440) 를 도시한다.
레거시 소프트웨어 엘리먼트의 일 예는 동적 환경 관리자 (Dynamic Environment Manager; DEM) 를 포함할 수도 있는데, 이에 한정되는 것은 아니다. 이것은 프로세서 슬립 이벤트들의 프로세서간 통지를 핸들링하는 소프트웨어 모듈이다. 예를 들어, 제 1 프로세서 (A) 는 DEM을 이용하여 제 2 프로세서 B 가 아이들로 들어갔거나/아이들로부터 나왔다는 통지를 수신한다. 더 최근의 하드웨어에서는, 이러한 소프트웨어 기능성은 루트 프로세서 모듈 (route processor module; RPM) 서브시스템/통신 프로토콜 내에 포함되었다. 다른 레거시 소프트웨어 엘리먼트들이 존재하며 본 발명의 범위 내에 포함된다.
레거시 하드웨어 엘리먼트의 예는 AMBA (Advanced Microcontroller Bus Architecture) 고성능 버스 (AMBA High-performance Bus; AHB) 를 포함할 수도 있는데 이에 한정되는 것은 아니다. 더 예전의 PCD들 (100) 상에서는, AHB 는 일차 시스템 버스를 포함하는 반면에, 더 최근의 PCD들 (100) 에서는 시스템 버스 패브릭 (fabric) 이 완전히 상이하고 그리고 AHB 버스는 신형 시스템 버스 패브릭을 통하여 통신하도록 아직 업데이트되지 않은 모듈들과 통신하기 위한 특수 애플리케이션들에 대해서만 이용된다. 다른 레거시 하드웨어 엘리먼트들이 존재하며 본 발명의 범위 내에 포함된다.
프레임워크 관리자 (440) 는 데이터 구조들, 예컨대 각각의 전술된 하드웨어 및 소프트웨어 엘리먼트들과 통신하는 노드들 (아래에서 설명됨) 을 관리하는 컴퓨터 명령어들의 라이브러리를 포함할 수도 있다. 프레임워크 관리자 (440) 는 도 5 의 점선 A 의 우측에서 도시된 바와 같은 노드들 (602, 622, 642, 및 646) 을 형성할 수도 있는 하나 이상의 리소스들을 생성하는 것을 담당할 수도 있다. 각각의 노드 (602, 622, 642, 및 646) 는 도 5 의 점선 A 의 좌측에 있는 각각의 소프트웨어 또는 하드웨어 엘리먼트의 표현 (representation) 또는 모델이다. 본 개시물의 잔여 부분에 대해서, 일반적이거나 비-특정의 노드에게는 도 6a 에서 도시된 바와 같이 참조 번호 601 이 부여될 것이다.
이전에 언급된 바와 같이, 도 5 의 각각의 예시적인 노드 (602, 622, 642, 및 646) 는 하나 이상의 리소스들을 포함할 수도 있다. 리소스는 소프트웨어 엘리먼트 또는 하드웨어 엘리먼트 또는 양쪽 모두를 포함할 수도 있다. 예를 들어, 제 1 노드 (602) 는 일반적으로 제 1 하드웨어 엘리먼트 또는 중앙 처리 유닛 (402) 과 대응하는 단일 리소스를 포함한다. 본 개시물에서 설명되는 창의적인 소프트웨어 아키텍처를 이용하면, 노드 (601) 의 각각의 리소스에는 하나 이상의 영숫자 문자들을 포함하는 고유 명칭이 제공될 수도 있다. 도 5 의 예시적인 실시형태에서는, 제 1 노드 (602) 의 리소스에는 "/core/cpu" 의 리소스 명칭이 지정되었다. 이러한 예시적인 리소스 명칭은 일반적으로 당업자들에게 공지된 종래의 파일 명명 구조들 (file naming structures) 에 대응한다. 그러나, 당업자에게 인식되는 바와 같이, 영숫자 문자들 및/또는 심벌들의 임의의 다른 조합을 포함하는 리소스 명칭들의 다른 타입들이 본 발명의 범위 내에 물론 포함된다.
도 5 의 예시적인 실시형태에서는, 제 2 노드 (622) 는 복수 개의 리소스들을 포함한다. 구체적으로 설명하면, 이러한 특정 예시적인 실시형태에서는, 제 2 노드 (622) 는 버스 중재기 또는 스케줄러 (422) 에 대응하는 단일 하드웨어 엘리먼트를 포함하는 제 1 리소스를 가진다. 제 2 노드 (622) 의 제 2 리소스는 일반적으로 버스 프로그램 A (444A) 의 제 1 소프트웨어 엘리먼트에 대응하는 소프트웨어 엘리먼트를 포함한다. 제 2 노드 (622) 의 제 3 리소스는 일반적으로 버스 프로그램 B (444B) 의 제 2 소프트웨어 엘리먼트에 대응하는 다른 소프트웨어 엘리먼트를 포함한다. 당업자는 주어진 노드 (601) 에 대한, 리소스들 및 리소스 타입들의 임의의 조합 및 임의의 개수가 본 발명의 범위 내에 물론 포함된다는 것을 인식한다.
또한, 도 5 는 일반적으로 두 개의 소프트웨어 엘리먼트들 (448, 450) 의 액션 또는 기능에 대응하는 제 1 클라이언트 (648) 를 도시한다. 도 5 의 예시적인 실시형태에서는, 클라이언트 (648) 는 일반적으로 휴대형 컴퓨팅 디바이스 (100) 에 의하여 지원되는 특정 애플리케이션 프로그램 내에서 발생할 수도 있는 키프레스 액션에 대응한다. 그러나, 당업자는 키프레스들 이외의 소프트웨어 엘리먼트들의 다른 액션들 및/또는 기능들이 본 발명의 범위 내에 물론 포함된다는 것을 인식한다. 클라이언트들 (648) 및 그들의 개별 생성에 대한 다른 세부 사항들은 도 12 와 연계하여 아래에서 설명될 것이다.
또한, 도 5 는 특정 아키텍쳐적 엘리먼트들 간의 관련성들을 도시한다. 예를 들어, 도 5 는 클라이언트 (648) 및 제 1 노드 (602) 간의 관련성을 도시한다. 구체적으로 설명하면, 제 1 클라이언트 (648) 는 점선들로 도시되며 리소스 "/core/cpu" 를 포함하는 제 1 노드 (602) 에 의하여 관리되고 핸들링되는 클라이언트 요청 (675A) 을 발생시킬 수도 있다. 통상적으로, 클라이언트 요청들 (675) 의 선결되거나 설정된 개수의 타입들이 존재한다. 클라이언트 요청들 (675) 은 도 13 과 연계하여 아래에서 더욱 상세히 설명될 것이다.
도 5 에 디스플레이된 다른 관련성들은 점선들 (680) 에 의하여 도시되는 종속성들을 포함한다. 종속성들은 다른 노드 (601) 의 개별 리소스들 간의 관련성들이다. 종속성 관련성은 보통 제 1 리소스 (A) 가 제 1 리소스 (A) 에게 정보를 제공할 수도 있는 제 2 리소스 (B) 에 의존한다는 것을 표시한다. 이러한 정보는 제 2 리소스 (B) 에 의하여 수행되는 동작의 결과일 수도 있고 또는 이것은 단순히 제 1 리소스 (A) 에 의하여 필요한 상태 정보 또는 이들의 임의의 조합을 포함할 수도 있다. 제 1 리소스 (A) 및 제 2 리소스 (B) 는 동일한 노드 (601) 의 일부일 수도 있고 또는 이들은 상이한 노드들 (601) 의 일부일 수도 있다.
도 5 에서는, 제 1 노드 (602) 는, 제 1 노드 (602) 와 함께 유래하고 그리고 622 에서 제 2 노드로 연장하는 종속성 화살표 (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) 을 인스턴스화 (instantiate) 하거나 생성하려고 시도할 것이다. 종속성 (680) 은 종속성을 지원하는 리소스가 존재하는 상태이거나 또는 그 종속성 (680) 에 관련하는 정보를 핸들링하기 위한 대기 상태에 있을 때에 완성된다.
예를 들어, 만일 단일 리소스 "/clk/cpu" 를 포함하는 제 3 노드 (642) 가 생성되지 않았다면, 제 1 노드 (602) 및 제 3 노드 (642) 사이에 존재하는 종속성 관련성 (680A) 때문에 단일 리소스 "/core/cpu" 를 가지는 제 1 노드 (602) 는 프레임워크 관리자 (440) 에 의하여 생성되거나 확립되지 않을 수도 있다. 제 3 노드 (642) 가 프레임워크 관리자 (440) 에 의하여 생성되기만 하면, 프레임워크 관리자 (440) 는 종속성 관련성 (680A) 때문에 제 2 노드 (602) 를 생성할 수도 있다.
만일 프레임워크 관리자 (440) 가 하나 이상의 이것의 종속성들 (680) 이 미완성이기 때문에 특정 노드 (601) 를 생성하거나 인스턴스화할 수 없다면, 프레임워크 관리자 (440) 는 프레임워크 관리자 (440) 에 의하여 성공적으로 생성되었던 그러한 노드들 (601) 에 대응하는 단계들을 계속하여 실시하거나 실행할 것이다. 프레임워크 관리자 (440) 는 일반적으로, 종속 리소스들이 생성되지 않은 미완성된 종속성들에 기인하여 존재하지 않을 수도 있는 특정 노드 (601) 에 대한 호를 스킵하고 해당 호에 대해 이러한 미완성된 상태를 반영하는 메시지들을 반환할 것이다.
도 4 에 도시된 것과 같은 멀티코어 환경에서는, 프레임워크 관리자 (440) 는 노드들 (601) 을 도 4 의 제 1, 제 2, 및 제 N 코어들 (424, 426, 및 428) 과 같은 별개의 코어들 상에서 생성하거나 인스턴스화할 수도 있다. 노드들 (601) 은 일반적으로, 노드들 (601) 이 서로에 대해 종속되지 않는 한 그리고 만일 아래에 설명되는 바와 같은 특정 노드의 대응하는 종속성들 모두가 완성된다면 멀티코어 환경에서 별개의 코어들 상에 그리고 병렬적으로 생성될 수도 있다.
도 6a 는 도 1 의 PCD (100) 의 리소스들을 관리하는 시스템에 대한 소프트웨어 아키텍처 (500B1) 의 제 2 양태의 일반적인 도면이다. 이러한 일반적인 도면에서, 각각의 노드 (601) 의 하나 이상의 리소스들에는 고유 명칭들이 제공되지 않았다. 도 6a 의 노드 또는 리소스 그래프 (500B1) 는 아키텍처 또는 프레임워크 관리자 (440) 에 의하여 지원되는 노드들 (601), 클라이언트들 (648), 이벤트들 (690), 및 질의 기능들 (695) 만을 포함한다. 각각의 노드 (601) 는 타원 형상 및 노드 (601) 내의 리소스들 간의 개별 종속성들을 나타내는 특정 방향들을 가지는 화살표들 (680) 을 이용하여 도시되었다.
도 6a 및 도 6b 에서 도시된 노드 아키텍처 내의 호들은 에일리어스 (alias), 또는 노드 (601) 내의 리소스의 실제 리소스 명칭에 대해서 만들어질 수도 있다. 예를 들어, 제 1 노드 (601A) 는 제 1 노드 (601A) 가 제 2 노드 (601B) 의 두 개의 리소스들 (리소스들 #2 및 #3) 에 종속된다는 것을 표시하는 종속성 화살표 (680A) 를 가진다. 또한, 도 6a 는 제 1 노드 (601A) 의 클라이언트 (648) 가 어떻게 클라이언트 요청 (675) 을 제 1 노드 (601A) 로 발행할 수도 있는지를 도시한다. 이러한 클라이언트 요청들 (675) 이 발행된 이후에, 제 2 노드 (601B) 는 이벤트 (690) 를 트리거링하거나 질의 (695) 에 대한 응답을 제공할 수도 있는데, 이들 내에서 이벤트 (690) 및 질의 (695) 에 대응하는 메시지들이 클라이언트 (648) 로 되돌아 흘러간다.
도 6b 는 도 1 의 PCD (100) 의 리소스들을 관리하는 시스템에 대한 소프트웨어 아키텍처 (500B2) 의 제 2 양태의 특정한 도면이다. 도 6b 는, 특정된, 또한 예시적인 리소스 명칭들을 가지는 노드들 (601), 및 도 5 의 그것들에 대응하는 클라이언트들 (648), 이벤트들 (690), 및 질의 기능들 (695) 만을 포함하는 노드 또는 리소스 그래프 (500B2) 를 도시한다. 각각의 노드 (601) 는 타원 형상 및 노드 (601) 내의 리소스들 간의 개별 종속성들을 나타내는 특정 방향들을 가지는 화살표들 (680) 을 이용하여 도시되었다.
예를 들어, 제 1 노드 (602) 는 제 1 노드 (602) 가 제 2 노드 (622) 의 세 개의 리소스들에 종속된다는 것을 표시하는 종속성 화살표 (680B) 를 가진다. 이와 유사하게, 제 2 소프트웨어 엘리먼트 (444B) 를 포함하고 총칭적으로 참조 문자 "C" 가 부여된 도 6 의 제 3 리소스 "/bus/ahb/sysB/" 는, 이러한 제 3 리소스 (C) 가 제 4 노드 (646) 의 단일 "/clk/sys/ahb" 리소스에 종속된다는 것을 표시하는 종속성 화살표 (680C) 를 가진다.
또한, 도 6b 는 하나 이상의 이벤트들 (690) 또는 질의 기능들 (695) 을 포함할 수도 있는 노드들 (601) 로부터의 출력 데이터를 도시한다. 질의 기능 (695) 은 이벤트 (690) 와 유사하다. 질의 기능 (695) 은 고유하거나 고유하지 않을 수도 있는 질의 핸들을 가질 수도 있다.
질의 기능은 일반적으로 외부에서 식별되지 않으며 그리고 일반적으로 이것은 상태를 가지지 않는다. 질의 기능 (695) 은 노드 (601) 의 특정 리소스의 상태를 결정하기 위하여 이용될 수도 있다. 질의 기능 (695) 및 이벤트들 (690) 은 확립된 클라이언트들 (648) 과의 관련성들을 가질 수도 있고, 그리고 이러한 관련성들은 방향 화살표들 (697) 에 의하여 표현되어 개별 이벤트 (690) 및 질의 기능 (695) 으로부터의 정보가 특정 클라이언트 (648) 로 전달된다는 것을 표시한다.
도 6 의 노드 또는 리소스 그래프들 (500B) 은, 메모리, 예컨대 도 4 의 메모리 (404) 내에 존재하며 프레임워크 관리자 (440) 에 의하여 관리되는 관련성들, 및 노드들 (601) 을 포함할 수도 있는 관련된 데이터 구조들을 표현한다. 노드 또는 리소스 그래프 (500B) 는 프레임워크 관리자 (440) 에 의하여 관리되는 개별 엘리먼트들 간의 관련성들을 식별하기 위한 그리고 소프트웨어 팀에 의한 문제 해결을 위한 유용한 툴로서 자동적으로 프레임워크 관리자 (440) 에 의하여 발생될 수 있다.
도 7a 는 PCD (100) 의 리소스(들)을 관리하기 위한 소프트웨어 아키텍처를 생성하기 위한 방법 (700A) 을 도시하는 흐름도이다. 블록 (705) 은 PCD (100) 의 리소스들을 관리하기 위한 방법 또는 프로세스 (700) 의 제 1 루틴이다. 블록 (705) 에서는, 루틴은 노드 구조 데이터를 수신하기 위하여 프레임워크 관리자 (440) 에 의하여 실행되거나 실시될 수도 있다. 노드 구조 데이터는 특정 노드 (601) 가 다른 노드들 (601) 과 함께 가질 수도 있는 종속성들을 개략화하는 종속성 어레이를 포함할 수도 있다. 노드 구조 데이터 및 이러한 루틴 또는 하부방법 (705) 에 대한 다른 세부 사항들이 도 8 과 연계하여 아래에 더 상세하게 설명될 것이다.
다음으로, 블록 (710) 에서는, 프레임워크 관리자 (440) 는 블록 (705) 에서 수신된 노드 구조 데이터의 일부인 종속성 데이터를 리뷰할 수도 있다. 결정 블록 (715) 에서는, 프레임워크 관리자 (440) 는 노드 구조 데이터가 리프 (leaf) 노드 (601) 를 정의하는지를 결정할 수도 있다. 리프 노드 (601) 란 일반적으로 노드 구조 데이터에 기초하여 생성될 노드가 임의의 종속성들을 가지지 않는다는 것을 의미한다. 만일 결정 블록 (715) 으로의 질의가 긍정적이라면, 이것은 현재 노드를 생성하기 위한 노드 구조 데이터가 임의의 종속성들을 가지지 않는다는 것을 의미하는데, 그러면 프레임워크 관리자 (440) 는 루틴 블록 (725) 으로 계속한다.
만일 결정 블록 (715) 으로의 질의가 부정적이라면, 이것은 "아니오" 브랜치가 결정 블록 (720) 에 대해서 후속되는데, 여기서 프레임워크 관리자는 노드 구조 데이터 내의 강한 종속성들 모두가 존재하는지를 결정한다. 강한 종속성은 리소스가 그것 없이는 존재할 수 없는 것을 포함할 수도 있다. 한편, 약한 종속성은 리소스가 종속 리소스를 선택적인 단계로서 이용할 수도 있는 것을 포함할 수도 있다. 약한 종속성은 약한 종속성을 가지는 노드 (601) 또는 노드 (601) 의 리소스가 심지어 약한 종속성이 존재하지 않을 때에도 노드 아키텍쳐 내에서 생성되거나 인스턴스화될 수도 있다는 것을 의미한다.
약한 종속성의 일 예는 다중 리소스들을 포함하는 유래된 리소스 (601) 에 대한 동작에 치명적이지 않은 최적화 피쳐를 포함할 수도 있다. 프레임워크 관리자 (440) 는 존재하는 모든 강한 종속성들에 대한 노드 또는 리소스를, 그리고 심지어는 생성되지 않은 약한 종속성들을 가지는 그러한 노드들 또는 리소스들에 대하여 약한 종속성이 존재하지 않을 때에도 생성하거나 인스턴스화할 수도 있다. 콜 백 피쳐가 이용되어 약한 종속성을 참조함으로써, 약한 종속성이 프레임워크 관리자 (440) 에게 이용 가능하게 될 때, 프레임워크 관리자 (440) 가 약한 종속성을 참조하는 각각의 콜백에게 약한 종속성들이 이제 이용가능하다는 것을 통지하도록 할 수도 있다.
만일 결정 블록 (720) 으로의 질의가 부정적이라면, "아니오" 브랜치가 블록 (727) 에 대해서 후속되는데, 여기서 노드 구조 데이터는 프레임워크 관리자 (440) 에 의하여 임시 스토리지, 예컨대 메모리 내에 저장되고, 그리고 프레임워크 관리자 (440) 는 이러한 비-인스턴스화된 (un-instantiated) 노드와 연관된 콜 백 피쳐를 생성한다.
만일 결정 블록 (715) 으로의 질의가 긍정적이라면, "예" 브랜치 루틴 (725) 에 대해서 후속하고, 여기서 노드 (601) 가 루틴 블록 (705) 에서 수신된 노드 구조 데이터에 기초하여 생성되거나 인스턴스화된다. 루틴 블록 (725) 의 다른 세부 사항들은 도 9 과 연계하여 아래에서 설명될 것이다. 다음으로, 블록 (730) 에서는, 프레임워크 관리자 (440) 는 새로 생성된 노드 (601) 를 그것의 고유 리소스 명칭(들)을 이용하여 공개함으로써, 다른 노드들 (601) 이 새로 생성된 노드 (601) 로 정보를 전송하거나 이로부터 정보를 수신할 수도 있도록 한다.
이제 도 7a 의 연속 흐름도인 도 7b 를 참조하면, 블록 (735) 에서는, 프레임워크 관리자 (440) 가 새로 생성된 노드 (601) 에 종속된 다른 노드들 (601) 에게 새로 생성된 노드 (601) 가 인스턴스화 되었으며 정보를 수신 또는 송신할 준비가 되었다는 것을 통보한다.
하나의 예시적인 양태에 따르면, 통보들은 도 6a 의 노드 (601B) 와 같은 종속 노드가 생성되면 즉시 트리거링되는데, 즉, 통보들은 재귀적으로 수행된다. 따라서 만일 도 6a 의 노드 (601B) 가 구성된다면, 노드 (601A) 는 즉시 통보받는다. 이러한 통보는 (노드 (601B) 가 노드 (601A) 의 최종 종속성이었기 때문에) 노드 (601A) 가 구성되도록 허용할 수도 있다. 노드 (601B) 의 구성은 다른 노드들 (601) 이 통보받도록 야기할 수도 있고, 이와 같은 방식으로 계속 진행한다. 노드 (601B) 는 노드 (601B) 에 종속된 최종 리소스가 완성될 때까지 완성되지 않는다.
제 2 의 약간 더 복잡한 구현형태는 통보들의 전부를 별개의 통보 큐 상에 배치하고, 시간 상 단일 시점에서 큐를 통해서 실시할 것인데, 즉, 통보들은 반복적으로 (iteratively) 수행된다. 따라서, 도 6a 의 노드 (601B) 가 구성되면, 노드 (601A) 로의 통보가 리스트 상에 배치된다. 그러면, 그 리스트가 실행되고 그리고 노드 (601A) 가 통보된다. 이것은 다른 추가적인 노드들 (601) (노드 (601A) 외의 노드들로서 도 6a 에는 미도시) 로의 통보가 동일한 리스트 상에 배치되도록 야기하며, 그리고 이 통보는 이제 노드 (601A) 로의 통보가 전송된 이후에 전송된다. 다른 노드들 (601) 로의 통보들 (노드 (601A) 로의 통보들 외의 통보들) 은 노드 (601B) 및 노드 (601A) 와 연관된 모든 작업이 완성된 이후까지 일어나지 않는다.
논리적으로는, 이러한 두 개의 구현형태들은 완벽하게 등가적인데, 그러나 이들은 구현될 때 상이한 메모리 소모를 가진다. 재귀적 실현예가 간단하지만, 스택 공간의 임의적인 양을 소모할 수 있고, 스택 소모가 종속성 그래프의 깊이의 함수이다. 반복적 구현형태가 다소 더 복잡하고 약간 더 많은 정적 메모리 (통보 리스트) 를 요구하는데, 하지만 스택 사용은 도 6a 에서 도시된 바와 같은 종속성 그래프의 깊이와 무관하게 일정하다.
또한, 블록 (735) 에서의 노드 생성의 통보는 다른 노드들로 한정되지 않는다. 이것은 에일리어스 구성을 위하여 내부적으로 이용될 수도 있다. 시스템 (500) 내의 임의적인 엘리먼트는 동일한 매커니즘을 이용하여 다른 노드들 뿐만이 아니라 노드 (또는 마커) 가 이용 가능해질 때 통보에 대해서 요청할 수 있다. 노드들 및 비-노드들 모두가 동일한 통보 매커니즘을 이용할 수도 있다.
결정 블록 (740) 에서는, 프레임워크 관리자 (440) 는 현재 노드 (601) 의 생성에 기초하여 다른 노드들 (601) 또는 약한 종속성들이 이제 생성 또는 인스턴스화되기 위하여 릴리스되는지를 결정한다. 결정 블록 (740) 은 일반적으로 어떤 종속성 관련성들 (680) 이 생성 또는 인스턴스화를 최근에 거쳤던 현재 노드에 의하여 달성되었기 때문에 리소스들이 이제 생성될 수도 있는지를 결정하고 있다.
만일 결정 블록 (740) 으로의 질의가 긍정적이라면, "예" 브랜치는 다시 루틴 블록 (725) 에 대해서 후속되는데, 여기서 방금 생성되었던 노드 (601) 에 의한 종속성의 달성 때문에 릴리스된 노드 (601) 는 이제 생성되거나 인스턴스화될 수도 있다.
만일 결정 블록 (740) 으로의 질의가 부정적이라면, "아니오" 브랜치는 블록 (745) 에 대해서 후속되는데, 여기에서 프레임워크 관리자 (440) 는 도 5 및 도 6 에서 도시된 바와 같은 소프트웨어 아키텍처의 엘리먼트들 간의 통신들을 관리할 수도 있다. 다음으로, 블록 (750) 에서는, 프레임워크 관리자 (440) 는 특정한 리소스와 연관된 리소스 명칭들을 이용하여 리소스들에 의하여 행해진 액션들을 계속하여 로깅하거나 기록할 수도 있다. 블록 (745) 은 프레임워크 관리자 (440) 또는 프레임워크 관리자 (440) 에 의하여 관리되는 엘리먼트들 중 임의의 것, 예컨대 리소스들, 노드들 (601), 클라이언트들 (648), 이벤트들 (695), 및 질의 기능들 (697) 에 의하여 행해진 임의의 액션 이후에 프레임워크 관리자 (440) 에 의하여 실행될 수도 있다. 프레임워크 관리자 (440) 가 특정 엘리먼트, 예컨대 노드 (601) 의 리소스를 생성했던 생성자들 (authors) 에 의하여 제공되는 그들의 고유한 식별자 또는 명칭에 따라서 각 엘리먼트에 의하여 수행되는 액션들을 목록화하는 활동성의 실시 로그 (running log) 를 유지할 수도 있다는 점에서, 블록 (745) 는 본 발명의 매우 중요한 한 가지 양태이다.
종래 기술과 비교하면, 블록 (750) 에서의, 시스템의 각 리소스에 지정된 고유 명칭들을 목록화하는 활동성의 이러한 로깅은 고유한 것이며 그리고 디버깅 및 에러 해결에서 이용되는 것과 같이 중요한 이점들을 제공할 수도 있다. 시스템 (500) 을 고유하게 만드는 많은 것들 중 다른 양태는, 별개의 팀들이 서로에 대해 독립적으로 상이한 하드웨어 및/또는 소프트웨어 엘리먼트들에 대해 작업할 수도 있다는 것인데, 여기서 각각의 팀은 다른 팀들 및/또는 원 장비 제조사 (OEM) 에 의하여 지정된 의미가 적고 일반적으로는 혼동을 야기하는 리소스 명칭들을 번역하기 위한 테이블들을 생성할 필요 없이, 고유하고 추적하기 용이한 리소스 명칭들을 이용할 수 있을 것이다.
다음으로, 결정 블록 (755) 에서는, 프레임워크 관리자 (440) 는 프레임워크 관리자 (440) 에 의하여 기록된 활동성의 로그가 요청되었는지를 결정한다. 만일 결정 블록 (755) 으로의 질의가 부정적이라면, "아니오" 브랜치는 프로세스의 끝에 대해서 후속되는데, 여기서 프로세스는 다시 루틴 (705) 으로 복귀한다. 만일 결정 블록 (755) 으로의 질의가 긍정적이라면, "예" 브랜치는 블록 (760) 으로 후속되는데, 여기에서 프레임워크 관리자 (440) 는 의미있는 리소스 명칭들 및 그 리소스 명칭들에 의하여 수행된 개별 액션들을 포함하는 활동성 로그를 출력 디바이스, 예컨대 프린터 또는 디스플레이 스크린 및/또는 양쪽 모두로 전송한다. 그러면, 프로세스는 위에서 설명된 루틴 블록 (705) 으로 복귀한다.
도 8 은 노드 구조 데이터를 PCD (100) 의 소프트웨어 아키텍처 내에 수신하기 위한, 도 7 의 서브-방법 또는 루틴 (705) 을 도시하는 흐름도이다. 블록 (805) 은 도 7 의 서브 방법 또는 루틴 (705) 의 제 1 단계이다. 블록 (805) 에서는, 프레임워크 관리자 (440) 는 소프트웨어 또는 하드웨어 엘리먼트, 예컨대 도 5 의 CPU (402) 및 클록 (442) 에 대한 고유 명칭을 수신할 수도 있다. 전에 논의된 바와 같이, 하나의 노드 (601) 는 적어도 하나 리소스를 참조하여야 한다. 각각의 리소스는 명칭을 가지고 있으며, 그 명칭은 시스템 (500) 내에서는 고유한 것이어야 한다. 시스템 (500) 내의 모든 엘리먼트들은 고유 명칭들로 식별될 수도 있다. 각각의 엘리먼트는 문자 관점으로부터 고유 명칭을 가진다. 다시 말하면, 일반적으로, 시스템 (500) 내에는 동일한 명칭을 가지는 두 개의 엘리먼트들이 존재하지 않는다.
이러한 시스템의 예시적인 양태들에 따르면, 노드들 (601) 의 리소스들은 일반적으로 시스템 전체에서 고유 명칭들을 가질 수도 있는데, 그러나 클라이언트 또는 이벤트 명칭들이 고유할 것이 요구되지는 않으며, 다만 이들은 원하는 바에 따라서 고유할 수도 있다.
편의를 위하여, 고유 명칭들을 생성하기 위하여 순방향 슬래시 "/" 를 채택하는 종래의 트리 파일 명명 구조 또는 파일 명명 "메타포 (metaphor)", 예컨대 CPU (402) 에 대한 "/core/cpu" 및 클록 (442) 에 대한 "/clk/cpu" 가 채택될 수도 있는데, 이에 한정되는 것은 아니다. 그러나, 당업자에 의하여 인식되는 바와 같이, 영숫자 문자들 및/또는 심벌들의 임의의 다른 조합을 포함하는 리소스 명칭들의 다른 타입들도 물론 본 발명의 범위 내에 포함된다.
다음으로, 블록 (810) 에서는, 프레임워크 관리자 (440) 는 생성되고 있는 노드 (601) 의 하나 이상의 리소스들과 연관된 하나 이상의 드라이버 기능들에 대한 데이터를 수신할 수도 있다. 일반적으로, 드라이버 기능은 특정 노드 (601) 에 대한 하나 이상의 리소스들에 의하여 완료되어야 하는 액션을 포함한다. 예를 들어, 도 6 에서는, 노드 (602) 의 리소스 /core/cpu 에 대한 드라이버 기능은, 요청되었던 처리의 요청된 양을 제공하기 위하여 자신이 요구하는 버스 대역폭의 양 및 CPU 클록 주파수를 요청할 수도 있다. 이러한 요청들은 노드들 (642) 및 노드 (622) 내의 리소스들의 클라이언트들 (미도시) 를 통해서 이루어질 수 있다. 노드 (642) 내의 /clk/cpu 에 대한 드라이버 기능은 일반적으로 물리적인 클록 주파수를 노드 (602) 의 /core/cpu 리소스로부터 이것이 수신한 요청에 따라서 실제로 설정하는 것을 담당할 수 있다.
블록 (815) 에서는, 프레임워크 관리자 (440) 는 노드 속성 데이터를 수신할 수도 있다. 노드 속성 데이터는 일반적으로 노드 정책들, 예컨대 보안 (노드가 사용자 공간 애플리케이션들에 의하여 액세스될 수 있는가), 원격가능성 (remotability) (노드가 시스템 내의 다른 프로세서들에 의하여 액세스될 수 있는가) 및 접근가능성 (리소스가 다중 병행 클라이언트들을 지원할 수 있는가) 를 정의하는 데이터를 포함한다. 또한, 프레임워크 관리자 (440) 는 리소스가 디폴트 프레임워크 거동, 예컨대 요청 평가 또는 로깅 정책을 중단 (override) 시키도록 허용하는 속성들을 정의할 수도 있다.
후속하여, 블록 (820) 에서는, 프레임워크 관리자 (440) 는 생성되는 중인 특정 노드 (601) 에 대한 맞춤화된 사용자 데이터를 수신할 수도 있다. 사용자 데이터는 "C" 프로그래밍 언어에 대한 당업자에 의하여 이해되는 바와 같은 보이드 (void) "star" 필드를 포함할 수도 있다. 또한, 사용자 데이터는 당업자에게 "trust me" 필드로서 알려진다. 예시적인 맞춤화된 사용자 데이터는 테이블들, 예컨대 주파수 테이블들, 레지스터 맴들 등을 포함할 수도 있지만, 이에 한정되는 것은 아니다. 블록 (820) 에서 수신된 사용자 데이터는 시스템 (500) 에 의하여 참조되지 않으며, 하지만 만일 맞춤화가 프레임워크 관리자 (440) 에 의하여 인식되지 않거나 완전히 지원되지 않는다면 리소스의 맞춤화를 허용한다. 이러한 사용자 데이터 구조는 특별한 또는 특정 사용들을 위하여 확장되도록 의도된 "C" 프로그래밍 언어 내의 기초 클래스이다.
당업자는 특별한 클래스의 특정 이용을 확장시키기 위한 데이터 구조들의 다른 종류들이 본 발명의 범위 내에 속한다는 것을 인식한다. 예를 들어, "C++" (C-플러스-플러스) 의 프로그래밍 언어에서는 등가적인 구조가 노드 (601) 내의 리소스에 대한 확장 매커니즘이 될 수 있는 키 워드 "public"을 포함할 수도 있다.
다음으로, 블록 (825) 에서는, 프레임워크 관리자 (440) 는 종속성 어레이 데이터를 수신할 수도 있다. 종속성 어레이 데이터는, 생성되고 있는 노드 (601) 가 종속된 하나 이상의 리소스들 (601) 의 고유한 및 특정 명칭들을 포함할 수도 있다. 예를 들어, 만일 도 6b 의 제 1 노드 (602) 가 생성되고 있었다면, 이러한 블록 (825) 에서는, 종속성 어레이 데이터는 제 1 노드 (602) 가 종속되는 제 2 노드 (622) 의 3 개의 리소스들의 리소스 명칭들 및 제 3 노드 (642) 의 단일 리소스 명칭을 포함할 수도 있다.
후속하여, 블록 (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) 은 데이터의 두 개의 열들을 포함할 수도 있다. 제 1 열은 리소스들 (601) 에 대응하는 에일리어스들 (1005) 을 포함할 수도 있고 그리고 제 2 열은 도 6 에 도시된 노드들 (601) 간의 관련성들을 관리하기 위하여 프레임워크 관리자 (440) 에 의하여 유지되는 노드들 (601) 의 실제 리소스 명칭들 (1010) 을 포함할 수도 있다. 동일한 리소스 (601) 에 대하여 다중 에일리어스들이 이용될 수도 있다. 에일리어스는 종속성으로서 인지될 수도 있고 그리고 도 12 와 연계하여 아래에서 설명되는 바와 같이 클라이언트의 생성 도중에 생성될 수도 있다.
명칭 테이블 (1000) 은 제 1 설계 팀, 예컨대 특정 하드웨어 및/또는 소프트웨어 엘리먼트들에 초점을 맞춘 소프트웨어 드라이버들을 위한 원 장비 제조사 (OEM) 로 하여금 하드웨어 또는 소프트웨어의 특정 피스 (piece) 상에 작업하고 있는 제 1 설계 팀에 대하여 내부적이고 상대적인 고유 명칭들을 제공하도록 허용한다. 명칭 테이블 (1000) 을 이용하여, 제 2 및 제 3 (또는 그 이상의) 외부 설계 팀들은 제 2 및 제 3 의 외부 설계 팀들의 그것들에 의하여 선호되는 에일리어스들을 이용하여 제 1 설계 팀의 (이러한 예에서는 OEM의) 하드웨어 또는 소프트웨어 엘리먼트들을 참조할 수 있을 수도 있다.
예를 들어, OEM 은 도 10 의 테이블 (1000) 의 제 1 행 및 제 2 열에서 도시된 바와 같은 명칭 "/cpu 0"을 도 5 의 중앙 처리 유닛 (402) 에게 지정할 수도 있다. 한편, OEM 에 대하여 상대적인 전문가들의 제 2 팀은 상이한 명칭 또는 에일리어스를 동일한 중앙 처리 유닛 (402) 에게 지정하기를 원할 수도 있다. 제 2 팀은 도 10 의 테이블 (1000) 의 제 1 행 및 제 1 열에서 도시된 바와 같은 "/cpu 0" 의 리소스 명칭에 대응하는 "메인 프로세서"의 에일리어스를 지정할 수도 있다.
도 11 은 PCD (100) 의 소프트웨어 아키텍처 내의 리소스의 에일리어스를 생성하기 위한 방법 (1100) 을 도시하는 흐름도이다. 블록 (1105) 이 리소스 (601) 의 에일리어스 (1005) 를 생성하기 위한 방법 (1100) 의 제 1 단계이다. 블록 (1105) 에서는, 프레임워크 관리자 (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) 가 생성되는 중인 특정한 클라이언트에 지정된 클라이언트 타입 카테고리를 수신한다. 이 서류에서의 클라이언트 타입 카테고리는 네 개의 타입들: (a) 필수 (required), (b) 임펄스, (c) 벡터, 및 (d) 등시적 (isochronous) 중 하나를 포함할 수도 있다. 클라이언트 타입 카테고리 리스트는 시스템 (500) 에 의하여 관리되는 중인 리소스들에, 그리고 노드들 (601) 의 리소스들에 의존하는 애플리케이션 프로그램들에 종속되어 확대될 수도 있다.
필수 카테고리는 일반적으로 필수 클라이언트 (648) 로부터 특정 리소스 (601) 로 전달되는 스칼라 값의 처리와 부합한다. 예를 들어, 필수 요청은 초당 수 백만 개의 명령어들 (millions of instructions per second; MIPs) 을 포함할 수도 있다. 한편, 임펄스 카테고리는 시작 시간 또는 중지 시간의 임의의 지정이 없이 시간의 특정 기간 내에 어떤 활동성을 완료하려는 요청의 처리와 부합한다.
등시성 카테고리는 일반적으로 통상적으로 재발생하고 있으며 명확한 (well-defined) 시작 시간 및 명확한 종료 시간을 가지는 액션에 대한 요청과 부합한다. 벡터 카테고리는 보통 직렬로 또는 병렬로 요구되는 다중 액션들의 일부인 데이터의 어레이와 일반적으로 부합한다.
후속하여, 블록 (1220) 에서는, 프레임워크 관리자 (440) 는 클라이언트 (648) 가 동기적 또는 비동기적으로서 지정되었는지 여부를 표시하는 데이터를 수신한다. 동기적 클라이언트 (648) 는, 통상적으로 노드의 리소스 (601) 가 데이터 및 그 리소스 (601) 가 동기적 클라이언트 (648) 로부터의 요청된 태스크를 완료하는 것을 완결했다는 표시를 반환할 때까지 프레임워크 관리자 (442) 에게 그 리소스 (601) 를 로킹 (lock) 하도록 요구하는 것이다.
반면에, 비동기적 클라이언트 (648) 는 프레임워크 관리자 (440) 에 의하여 액세스되는 하나 이상의 스레드들 (436) (도 4 참조) 에 의하여 병렬적으로 핸들링될 수도 있다. 프레임워크 (440) 는 스레드 (436) 로의 콜백을 생성할 수도 있고, 그리고 콜백이 개별 스레드 (436) 에 의하여 실행되었을 때 소정 값을 반환할 수도 있다. 당업자는 비동기적 클라이언트 (648) 가 동기적 클라이언트 (648) 가 동기적 클라이언트 (648) 의 태스크가 실행되는 동안에 그러하듯이 리소스를 로킹하지 않는다는 것을 인식한다.
블록 (1220) 이후에는, 결정 블록 (1225) 에서는, 프레임워크 관리자 (440) 는 클라이언트 (645) 에 의하여 식별된 리소스가 이용가능한지를 결정한다. 만일 결정 블록 (1225) 으로의 질의가 부정적이라면, "아니오" 브랜치는 블록 (1230) 으로 후속되는데, 여기에서 클라이언트 (648) 가 지금은 생성될 수 없다는 것을 표시하는 널 (null) 값 또는 메시지가 사용자에게 반환된다.
만일 결정 블록 (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) 이다. 방법 (1300) 은 일반적으로 도 7 및 도 12 와 연계하여 위에서 설명된 바와 같은 클라이언트 생성 및 노드 생성 이후에 실행된다. 블록 (1305) 은 리소스 (601) 에 대하여 클라이언트 요청 (675) 을 생성하기 위한 방법 (1300) 의 제 1 단계이다. 이러한 방법 (1300) 은 어떻게 후속하는 요청들 (675) 의 3 개의 타입들: (a) 필수, (b) 임펄스, 및 (c) 벡터가 프레임워크 관리자 (440) 에 의하여 핸들링되는지를 설명할 것이다. 요청 (675) 의 제 4 타입인 (d) 등시성 요청의 핸들링은 도 15 와 연계하여 아래에서 설명될 것이다. 위에서 언급된 요청들 (675) 의 명칭들이 제안하는 바와 같이, 클라이언트 요청들 (675) 은 일반적으로 도 12 와 연계하여 생성되고 설명되었던 클라이언트 타입들과 부합한다.
블록 (1305) 에서는, 프레임워크 관리자 (440) 는 특정 클라이언트 요청 (675) 과 연관된 데이터, 예컨대 위에서 언급된 세 개: (a) 필수, (b) 임펄스, 및 (c) 벡터 중 하나를 수신할 수도 있다. 필수 요청과 연관된 데이터는 일반적으로 필수 클라이언트 (648) 로부터 특정 리소스 (601) 로 전달되는 스칼라 값을 포함한다. 예를 들어, 필수 요청은 초당 수 백만 개의 명령어들 (MIPs) 을 포함할 수도 있다. 한편, 임펄스 요청은 시작 시간 또는 중지 시간의 임의의 지정이 없이 시간의 특정 기간 내에 어떤 활동성을 완료하려는 요청을 포함한다. 벡터 요청에 대한 데이터는 일반적으로 직렬로 또는 병렬로 완료되도록 요구되는 다중 액션들의 어레이를 포함한다. 벡터 요청은 값들의 임의의 길이를 포함할 수도 있다. 벡터 요청은 일반적으로 사이즈 값 및 값들의 어레이를 가진다. 노드 (601) 의 각각의 리소스는 벡터 요청을 지원하기 위하여 확장되어 포인터 필드를 가질 수도 있다. "C" 프로그래밍 언어에서는, 포인터 필드는 당업자에 의하여 이해되는 바와 같이 유니온 함수 (union function) 에 의하여 지원된다.
다음으로, 블록 (1310) 에서는, 프레임워크 관리자 (440) 는 도 13 과 연계하여 위에서 설명된 방법에 의하여 생성되었던 클라이언트 (648) 를 통과하여 요청을 발행한다. 후속하여, 블록 (1315) 에서는, 프레임워크 관리자 (440) 는 요청이 필수 타입 또는 벡터 타입이라면 클라이언트를 통과하여 전달되는 중인 요청 데이터를 더블 버퍼화한다. 만일 요청이 임펄스 타입이라면, 블록 (1315) 은 프레임워크 관리자 (1440) 에 의하여 스킵된다.
필수 요청들에 대해서는, 이러한 블록 (1315) 내에서, 이전 요청으로부터의 값들이 메모리 내에 유지됨으로써, 프레임워크 관리자 (440) 가 이전 요청된 값들 및 요청된 값들의 현재 세트 사이에 임의의 차분이 존재하는지를 결정할 수 있다. 벡터 요청들에 대해서는, 비록 노드 (601) 의 리소스가 특정 구현형태에서 원하는 바와 같이 이전 요청을 유지할 수도 있지만, 이전 요청들은 일반적으로 메모리 내에 유지되지 않는다. 그러므로, 블록 (1315) 은 요청들의 벡터 타입들에 대해서는 선택적이다.
블록 (1320) 에서는, 프레임워크 관리자 (440) 는 요청된 값들의 이전 세트 및 요청된 값들의 현재 세트 간의 델타 또는 차분을 연산한다. 결정 블록 (1325) 에서는, 프레임워크 관리자는 요청된 값들의 현재 세트가 요청된 값들의 이전 세트와 동일한지를 결정한다. 다시 말하면, 프레임워크 관리자 (440) 는 요청된 값들의 현재 세트 및 요청된 값들의 이전 세트 사이에 차분이 존재하는지를 결정한다. 만일 요청된 값들의 현재 세트 및 이전 세트 간에 차분이 존재하지 않으면, "예" 브랜치는 (블록들 (1330) 내지 블록 (1370) 을 스킵하면서) 블록 (1375) 으로 후속되는데, 여기서 프로세스는 끝난다.
만일 결정 블록 (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 는 128 MHz 및 160 MHz 에서만 실시할 수도 있는데, 하지만 요청된 상태는 150 MHz 일 수도 있다. 이러한 경우에서는, 드라이버 기능은 160 MHz 가 요청된 상태를 초과하지만, 거기서 실시하여야 한다.
다음으로, 블록 (1355) 에서는, 프레임워크 (440) 는 드라이버 기능을 블록 (1350) 에서 실행했던 리소스로부터 상태 제어를 수신한다. 후속하여, 블록 (1360) 에서는, 만일 그 리소스에 대해 정의된다면, 이벤트들 (690) 이 트리거링됨으로써, 데이터가 이벤트 (690) 에 대응하는 클라이언트 (648) 로 다시 전달되도록 할 수도 있다. 이벤트들은 다른 스레드에서 처리될 수도 있다. 이것은 로킹된 리소스들을 이용하여 걸리는 시간의 양을 최소화할 수도 있고, 그리고 도 4 에 도시된 바와 같은 멀티코어 시스템 내에 더 많은 병렬 동작을 허용한다. 하나 이상의 이벤트들 (690) 이, 어떻게 요청이 이러한 방법 (1300) 에서 설명되는 바와 같이 리소스에 대하여 정의될 수도 있는지와 유사한 방식으로 리소스에 대하여 정의될 수도 있다. 다시 말하면, 이벤트 생성 프로세스는 대략적으로 클라이언트 생성 프로세스에 필적한다. 이 이벤트들과 함께 상이한 한 가지 점은, 특정한 임계들이 경과될 때에만 트리거링되는 이벤트들을 정의하는 것이 가능하다는 것이다.
임계들에 기초하여서만 트리거링되는 이벤트들의 이러한 정의 작업은, 시스템 과부하인가 조건을 표시할 수 있는 리소스가 과다가입 (리소스가 지원할 수 있는 것보다 더 많은 동시 사용자들을 가진다) 되고 있는 경우, 또는 리소스가 떨어져가거나 없어져서 다른 것들이 셧오프되어 시스템이 과다가입되었을 때에 디스에이블되었던 기능성을 복원하도록 하는 경우 등의 통보를 허용한다. 이벤트 등록이 임계들과 함께 이루어질 수도 있기 때문에, 이것은 이벤트 통보 시에 시스템이 수행하여야 하는 작업의 양을 감소시켜 이것이 정말 필요한 어떤 일이 존재하는 경우에만 발생하도록 할 수 있다. 또한, 모든 상태 변동시에 이벤트에 대해서 등록하는 것이 가능하다.
다음으로, 선택적인 블록 (1365) 에서는, 만일 처리되는 중인 요청이 벡터 요청이라면, 이러한 선택적인 블록 (1365) 은 보통 수행된다. 선택적인 블록 (1365) 은 벡터 포인터가 여전히 사용자가 그 벡터로 전달했던 것과 동일한 데이터 상에 포지셔닝되는지 여부를 평가하기 위한 점검 또는 결정을 포함한다. 만일 이러한 선택적인 블록 (1365) 으로의 질의가 긍정적이라면, 이것은 포인터가 여전히 사용자에 의하여 벡터로 전달되었던 것과 동일한 데이터를 가리키고 있다는 것을 의미하는데, 그러면 포인터는 클리어링되어 과거 데이터로의 참조들이 유지되지 않도록 할 수 있다. 이러한 선택적인 블록 (1365) 은 일반적으로 수행되어, 임펄스 요청 및 필수 요청과 비교하여, 벡터 요청이 처리되는 중일 때 위에서 설명된 이중 버퍼링 블록 (1315) 을 설명한다.
후속하여, 블록 (1370) 에서는, 프레임워크 (440) 가 요청된 리소스를 언로킹 (unlock) 함으로써, 다른 클라이언트 요청들 (648) 이 특정 노드 (601) 의 현재의 그러나 이제 릴리스된 요청된 리소스에 의하여 핸들링될 수도 있도록 할 수 있다. 그러면, 프로세스는 다음 클라이언트 요청을 수신하기 위하여 제 1 블록 (1305) 으로 복귀한다.
도 14 는 PCD (100) 의 리소스에 대한 등시성 클라이언트 요청 내에서 요청된 작업을 도시하는 도면 (1400) 이다. 도면 (1400) 은 X-축 및Y-축을 가지는 그래프를 포함한다. X-축은 일반적으로 경과된 시간을 포함하는 한편 Y-축은 요청된 액션 값, 예컨대 요청된 초당 수백 만개의 명령어들 (MIPs) 을 포함한다. 이전에 언급된 바와 같이 등시성 클라이언트 요청은 일반적으로 명확한 시작 시간 (A) 및 명확한 종료 시간 또는 데드라인 (C) 를 포함한다. 도 14 에 도시된 예시적인 구현형태에서는, 그래프는 150 MIP들의 요청된 작업이 시간 (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) 에 상대적으로 디바이스 외에서 수행될 수도 있다는 것을 표시하였다. 최적화 프로세스는 많은 상이한 변수들, 예컨대 전력 소비 및 응답성 (responsiveness) 을 고려하면서 어떻게 작업이 시작 시간 및 데드라인 사이에서 최적으로 완료될 수도 있을지를 결정하려고 시도할 수도 있다. 몇 가지 예시적인 구현형태들에서는, 이러한 블록 (1367) 은 본 발명의 범위에서 벗어나지 않으면서 모두 전체적으로 함께 스킵될 수도 있다. 그러면, 프로세스는 다음 클라이언트 요청 (675) 의 처리를 위하여 도 13 의 블록 (1305) 으로 복귀한다.
본 명세서에서 설명된 프로세스들 또는 프로세스 흐름들 내의 특정 단계들은 본 발명이 설명된 바와 같이 기능하도록 하기 위하여 다른 것들에 자연적으로 선행한다. 그러나, 이러한 순서 또는 시퀀스가 본 발명의 기능성을 변경하지 않는다면, 본 발명은 이러한 단계의 순서에 한정되지 않는다. 즉, 어떤 단계들은 본 발명의 범위 및 사상에서 벗어나지 않으면서 다른 단계 이전에, 이후에, 또는 병렬적으로 (실질적으로 동시에) 수행될 수도 있다는 것이 인식된다. 몇 가지 실례들에서는, 어떤 단계들은 본 발명을 벗어나지 않으면서 생략되거나 수행되지 않을 수도 있다. 더 나아가, 단어들 "그 이후에", "그러면", "다음으로" 등은 단계들의 순서를 제한하려고 의도되지 않는다. 이러한 단어들은 독자를 예시적인 방법들의 설명을 통해서 인도하기 위하여 이용될 뿐이다.
추가적으로, 프로그래밍의 당업자는, 예를 들어 본 명세서 내의 흐름도들 및 연관된 발명을 실시하기 위한 구체적인 내용에 기초하여 어려움 없이 개시된 발명을 구현하기 위한 컴퓨터 코드를 작성하거나 적절한 하드웨어 및/또는 회로들을 식별할 수 있다.
그러므로, 프로그램 코드 명령어들의 특정한 세트 또는 세부적인 하드웨어 디바이스들의 개시는 어떻게 본 발명을 생산하고 사용할 지에 대한 적합한 이해를 위하여 필요한 것으로 간주되지 않는다. 청구된 컴퓨터로 구현된 프로세스들의 진보적인 기능성은 위의 발명을 실시하기 위한 구체적인 내용에서 그리고 다양한 프로세스 흐름들을 도시할 수도 있는 도면들과 함께 더욱 상세히 설명된다.
하나 이상의 예시적인 양태들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합으로 구현될 수도 있다. 소프트웨어로 구현되면, 그 기능들은 하나 이상의 명령들 또는 코드로서 컴퓨터 판독가능 매체 상에 저장되거나 전송될 수도 있다. 컴퓨터 판독가능 매체는 한 장소에서 다른 장소로의 컴퓨터 프로그램의 전송을 용이하게 하는 임의의 매체를 포함하는 컴퓨터 스토리지 매체들 및 통신 매체들 양쪽 모두를 포함한다. 스토리지 매체들은 컴퓨터에 의해 액세스될 수 있는 임의의 이용 가능한 매체들일 수도 있다. 한정이 아니라 예를 들기 위해서, 이러한 컴퓨터 판독가능 매체들은 RAM, ROM, EEPROM, CD-ROM 또는 다른 광 디스크 스토리지, 자기 디스크 스토리지, 또는 다른 자기 저장 디바이스들, 또는 원하는 프로그램 코드를 컴퓨터에 의해 액세스될 수도 있는 명령들 또는 데이터 구조들의 형태로 운반하거나 저장하는데 이용될 수 있는 임의의 다른 매체를 포함할 수도 있다.
또한, 임의의 접속이 적절히 컴퓨터 판독가능 매체로서 칭해진다. 예를 들어, 만일 소프트웨어가 웹사이트, 서버, 또는 다른 원격 소스로부터 동축 케이블, 광섬유 케이블, 연선 (twisted pair), 디지털 가입자 회선 (digital subscriber line; DSL), 또는 무선 기술들, 예컨대 적외선, 라디오, 및 마이크로파를 이용하여 송신되면, 이러한 동축 케이블, 광섬유 케이블, 연선, DSL, 또는 적외선, 라디오, 및 마이크로파와 같은 무선 기술들은 매체의 정의에 포함된다.
본 명세서에서 사용될 때, 디스크 (disk 및 disc) 는 콤팩트 디스크 (compact disc, CD), 레이저 디스크, 광 디스크, 디지털 다용도 디스크 (digital versatile disc; DVD), 플로피 디스크 (floppy disk) 및 블루레이 디스크를 포함하는데, 디스크 (disk) 들은 보통 데이터를 자기적으로 재생하지만, 디스크 (disc) 들은 레이저들을 이용하여 광학적으로 데이터를 재생한다. 상기한 것들의 조합들도 역시 컴퓨터 판독가능 매체들의 범위 내에 포함되어야 한다.
비록 선택된 양태들이 상세하게 도시되고 설명되었지만, 후속하는 특허청구범위에 의하여 정의되는 바와 같은 본 발명의 사상 및 범위로부터 벗어나지 않으면서 다양한 대체들 및 변경들이 이루어질 수도 있다는 것이 이해될 것이다.

Claims (40)

  1. 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법으로서,
    노드를 형성하기 위한 노드 구조 데이터 (node structure data) 를 수신하는 단계로서, 상기 노드 구조 데이터는 상기 노드의 일부인 각 리소스에 대한 고유 명칭을 포함하는, 상기 노드 구조 데이터를 수신하는 단계;
    상기 노드 구조 데이터를 하나 이상의 종속성들에 대하여 리뷰하는 단계;
    종속성과 연관된 각 리소스가 노드 프레임워크 내에 존재하는지를 결정하는 단계;
    종속성과 연관된 리소스가 존재하지 않는다면, 상기 노드 구조 데이터를 임시 스토리지에 저장하는 단계;
    각 종속성에 대한 각 리소스가 존재한다면, 상기 노드 및 상기 노드의 하나 이상의 대응하는 리소스들을 생성하는 단계; 및
    상기 노드가 생성되면, 통신들을 처리하기 위한 상태 대기 (state ready) 의 노드의 하나 이상의 리소스들에 대응하는 하나 이상의 고유 명칭들을 이용하여 상기 노드 프레임워크 내에서 상기 노드를 공개 (publish) 하는 단계를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법.
  2. 제 1 항에 있어서,
    상기 각 리소스는 소프트웨어 엘리먼트와 하드웨어 엘리먼트 중 적어도 하나의 엘리먼트를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법.
  3. 제 1 항에 있어서,
    현재 노드에 종속된 하나 이상의 노드들에게 상기 현재 노드의 생성을 통보하는 단계를 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법.
  4. 제 1 항에 있어서,
    상기 노드 프레임워크의 하나 이상의 노드들 간의 통신들을 관리하는 단계, 및
    상기 각 리소스의 활동성을 상기 리소스의 고유 명칭으로 메모리에 기록하는 단계를 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법.
  5. 제 4 항에 있어서,
    기록된 상기 각 리소스의 활동성을 상기 리소스의 고유 명칭으로 출력 디바이스에 디스플레이하는 단계를 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법.
  6. 제 5 항에 있어서,
    상기 출력 디바이스는, 비디오 디스플레이, 파일, 시리얼 포트, 무선 인터페이스, 및 프린터 중 적어도 하나를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법.
  7. 제 1 항에 있어서,
    벡터 데이터를 포함하는 클라이언트 요청 데이터를 수신하는 단계를 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법.
  8. 제 7 항에 있어서,
    벡터 요청이 실행된 이후에 벡터 포인터의 상태를 점검하는 단계를 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법.
  9. 제 8 항에 있어서,
    상기 벡터 포인터를 리셋하는 단계를 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법.
  10. 제 1 항에 있어서,
    상기 휴대형 컴퓨팅 디바이스는, 모바일 전화기, 개인 휴대 정보 단말기 (personal digital assistant), 페이저 (pager), 스마트폰, 내비게이션 디바이스, 및 무선 접속 또는 링크를 갖는 핸드헬드 컴퓨터 중 적어도 하나를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법.
  11. 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템으로서,
    상기 컴퓨터 시스템은 프로세서를 포함하고,
    상기 프로세서는,
    노드를 형성하기 위한 노드 구조 데이터를 수신하는 것으로서, 상기 노드 구조 데이터는 상기 노드의 일부인 각 리소스에 대한 고유 명칭을 포함하는, 상기 노드 구조 데이터를 수신하고;
    상기 노드 구조 데이터를 하나 이상의 종속성들에 대하여 리뷰하고;
    종속성과 연관된 각 리소스가 노드 프레임워크 내에 존재하는지를 결정하도록 동작가능하고,
    종속성과 연관된 리소스가 존재하지 않는다면, 상기 프로세서는 상기 노드 구조 데이터를 임시 스토리지에 저장하도록 동작가능하고;
    각 종속성에 대한 각 리소스가 존재한다면, 상기 프로세서는 상기 노드 및 상기 노드의 하나 이상의 대응하는 리소스들을 생성하도록 동작가능하며;
    상기 노드가 생성되면, 상기 프로세서는 통신들을 처리하기 위한 상태 대기의 노드의 하나 이상의 리소스들에 대응하는 하나 이상의 고유 명칭들을 이용하여 상기 노드 프레임워크 내에서 상기 노드를 공개하도록 동작가능한, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  12. 제 11 항에 있어서,
    상기 각 리소스는 소프트웨어 엘리먼트와 하드웨어 엘리먼트 중 적어도 하나의 엘리먼트를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  13. 제 12 항에 있어서,
    상기 프로세서는, 현재 노드에 종속된 하나 이상의 노드들에게 상기 현재 노드의 생성을 통보하도록 동작가능한, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  14. 제 11 항에 있어서,
    상기 프로세서는, 상기 노드 프레임워크의 하나 이상의 노드들 간의 통신들을 관리하고 상기 각 리소스의 활동성을 상기 리소스의 고유 명칭으로 메모리에 기록하도록 동작가능한, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  15. 제 14 항에 있어서,
    상기 프로세서는, 기록된 상기 각 리소스의 활동성을 상기 리소스의 고유 명칭으로 출력 디바이스에 디스플레이하도록 동작가능한, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  16. 제 15 항에 있어서,
    상기 출력 디바이스는, 비디오 디스플레이, 파일, 시리얼 포트, 무선 인터페이스, 및 프린터 중 적어도 하나를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  17. 제 11 항에 있어서,
    상기 프로세서는 또한, 벡터 데이터를 포함하는 클라이언트 요청 데이터를 수신하도록 동작가능한, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  18. 제 11 항에 있어서,
    상기 프로세서는 또한, 벡터 요청이 실행된 이후에 벡터 포인터의 상태를 점검하도록 동작가능한, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  19. 제 18 항에 있어서,
    상기 프로세서는 또한, 상기 벡터 포인터를 리셋하도록 동작가능한, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  20. 제 11 항에 있어서,
    상기 휴대형 컴퓨팅 디바이스는, 모바일 전화기, 개인 휴대 정보 단말기, 페이저, 스마트폰, 내비게이션 디바이스, 및 무선 접속 또는 링크를 갖는 핸드헬드 컴퓨터 중 적어도 하나를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  21. 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템으로서,
    노드를 형성하기 위한 노드 구조 데이터를 수신하는 수단으로서, 상기 노드 구조 데이터는 상기 노드의 일부인 각 리소스에 대한 고유 명칭을 포함하는, 상기 노드 구조 데이터를 수신하는 수단;
    상기 노드 구조 데이터를 하나 이상의 종속성들에 대하여 리뷰하는 수단;
    종속성과 연관된 각 리소스가 노드 프레임워크 내에 존재하는지를 결정하는 수단;
    종속성과 연관된 리소스가 존재하지 않는다면, 상기 노드 구조 데이터를 임시 스토리지에 저장하는 수단;
    각 종속성에 대한 각 리소스가 존재한다면, 상기 노드 및 상기 노드의 하나 이상의 대응하는 리소스들을 생성하는 수단; 및
    상기 노드가 생성되면, 통신들을 처리하기 위한 상태 대기의 노드의 하나 이상의 리소스들에 대응하는 하나 이상의 고유 명칭들을 이용하여 상기 노드 프레임워크 내에서 상기 노드를 공개하는 수단을 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  22. 제 21 항에 있어서,
    상기 각 리소스는 소프트웨어 엘리먼트와 하드웨어 엘리먼트 중 적어도 하나의 엘리먼트를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  23. 제 22 항에 있어서,
    현재 노드에 종속된 하나 이상의 노드들에게 상기 현재 노드의 생성을 통보하는 수단을 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  24. 제 21 항에 있어서,
    상기 노드 프레임워크의 하나 이상의 노드들 간의 통신들을 관리하고 상기 각 리소스의 활동성을 상기 리소스의 고유 명칭으로 메모리에 기록하는 수단을 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  25. 제 24 항에 있어서,
    기록된 상기 각 리소스의 활동성을 상기 리소스의 고유 명칭으로 출력 디바이스에 디스플레이하는 수단을 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  26. 제 25 항에 있어서,
    상기 출력 디바이스는, 비디오 디스플레이, 파일, 시리얼 포트, 무선 인터페이스, 및 프린터 중 적어도 하나를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  27. 제 21 항에 있어서,
    벡터 데이터를 포함하는 클라이언트 요청 데이터를 수신하는 수단을 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  28. 제 21 항에 있어서,
    벡터 요청이 실행된 이후에 벡터 포인터의 상태를 점검하는 수단을 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  29. 제 28 항에 있어서,
    상기 벡터 포인터를 리셋하는 수단을 더 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  30. 제 21 항에 있어서,
    상기 휴대형 컴퓨팅 디바이스는, 모바일 전화기, 개인 휴대 정보 단말기, 페이저, 스마트폰, 내비게이션 디바이스, 및 무선 접속 또는 링크를 갖는 핸드헬드 컴퓨터 중 적어도 하나를 포함하는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 컴퓨터 시스템.
  31. 컴퓨터 판독가능 프로그램 코드를 포함하는 컴퓨터 이용가능 매체를 포함하는 컴퓨터 프로그램 제품으로서,
    상기 컴퓨터 판독가능 프로그램 코드는, 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 방법을 구현하기 위해 실행되도록 구성되고,
    상기 방법은,
    노드를 형성하기 위한 노드 구조 데이터를 수신하는 단계로서, 상기 노드 구조 데이터는 상기 노드의 일부인 각 리소스에 대한 고유 명칭을 포함하는, 상기 노드 구조 데이터를 수신하는 단계;
    상기 노드 구조 데이터를 하나 이상의 종속성들에 대하여 리뷰하는 단계;
    종속성과 연관된 각 리소스가 노드 프레임워크 내에 존재하는지를 결정하는 단계;
    종속성과 연관된 리소스가 존재하지 않는다면, 상기 노드 구조 데이터를 임시 스토리지에 저장하는 단계;
    각 종속성에 대한 각 리소스가 존재한다면, 상기 노드 및 상기 노드의 하나 이상의 대응하는 리소스들을 생성하는 단계; 및
    상기 노드가 생성되면, 통신들을 처리하기 위한 상태 대기의 노드의 하나 이상의 리소스들에 대응하는 하나 이상의 고유 명칭들을 이용하여 상기 노드 프레임워크 내에서 상기 노드를 공개하는 단계를 포함하는, 컴퓨터 이용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  32. 제 31 항에 있어서,
    상기 각 리소스는 소프트웨어 엘리먼트와 하드웨어 엘리먼트 중 적어도 하나의 엘리먼트를 포함하는, 컴퓨터 이용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  33. 제 31 항에 있어서,
    상기 방법을 구현하는 상기 컴퓨터 판독가능 프로그램 코드는, 현재 노드에 종속된 하나 이상의 노드들에게 상기 현재 노드의 생성을 통보하는 것을 더 포함하는, 컴퓨터 이용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  34. 제 31 항에 있어서,
    상기 방법을 구현하는 상기 컴퓨터 판독가능 프로그램 코드는, 상기 노드 프레임워크의 하나 이상의 노드들 간의 통신들을 관리하고 상기 각 리소스의 활동성을 상기 리소스의 고유 명칭으로 메모리에 기록하는 것을 더 포함하는, 컴퓨터 이용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  35. 제 34 항에 있어서,
    상기 방법을 구현하는 상기 컴퓨터 판독가능 프로그램 코드는, 기록된 상기 각 리소스의 활동성을 상기 리소스의 고유 명칭으로 출력 디바이스에 디스플레이하는 것을 더 포함하는, 컴퓨터 이용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  36. 제 35 항에 있어서,
    상기 출력 디바이스는, 비디오 디스플레이, 파일, 시리얼 포트, 무선 인터페이스, 및 프린터 중 적어도 하나를 포함하는, 컴퓨터 이용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  37. 제 31 항에 있어서,
    상기 방법을 구현하는 상기 컴퓨터 판독가능 프로그램 코드는, 벡터 데이터를 포함하는 클라이언트 요청 데이터를 수신하는 것을 더 포함하는, 컴퓨터 이용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  38. 제 31 항에 있어서,
    상기 방법을 구현하는 상기 컴퓨터 판독가능 프로그램 코드는, 벡터 요청이 실행된 이후에 벡터 포인터의 상태를 점검하는 것을 더 포함하는, 컴퓨터 이용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  39. 제 38 항에 있어서,
    상기 방법을 구현하는 상기 컴퓨터 판독가능 프로그램 코드는, 상기 벡터 포인터를 리셋하는 것을 더 포함하는, 컴퓨터 이용가능 매체를 포함하는 컴퓨터 프로그램 제품.
  40. 제 31 항에 있어서,
    상기 휴대형 컴퓨팅 디바이스는, 모바일 전화기, 개인 휴대 정보 단말기, 페이저, 스마트폰, 내비게이션 디바이스, 및 무선 접속 또는 링크를 갖는 핸드헬드 컴퓨터 중 적어도 하나를 포함하는, 컴퓨터 이용가능 매체를 포함하는 컴퓨터 프로그램 제품.
KR1020137009467A 2010-09-15 2011-07-08 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 시스템 및 방법 KR20130084659A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/882,395 2010-09-15
US12/882,395 US8615755B2 (en) 2010-09-15 2010-09-15 System and method for managing resources of a portable computing device
PCT/US2011/043282 WO2012036776A1 (en) 2010-09-15 2011-07-08 System and method for managing resources of a portable computing device

Publications (1)

Publication Number Publication Date
KR20130084659A true KR20130084659A (ko) 2013-07-25

Family

ID=44514988

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020137009467A KR20130084659A (ko) 2010-09-15 2011-07-08 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 시스템 및 방법

Country Status (6)

Country Link
US (1) US8615755B2 (ko)
EP (1) EP2616941A1 (ko)
JP (1) JP2013537340A (ko)
KR (1) KR20130084659A (ko)
CN (1) CN103098033A (ko)
WO (1) WO2012036776A1 (ko)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US8806502B2 (en) 2010-09-15 2014-08-12 Qualcomm Incorporated Batching resource requests in a portable computing device
US9152523B2 (en) 2010-09-15 2015-10-06 Qualcomm Incorporated Batching and forking resource requests in a portable computing device
US8631414B2 (en) 2010-09-15 2014-01-14 Qualcomm Incorporated Distributed resource management in a portable computing device
US20120240125A1 (en) * 2011-03-18 2012-09-20 Qnx Software Systems Co System Resource Management In An Electronic Device
US8959223B2 (en) * 2011-09-29 2015-02-17 International Business Machines Corporation Automated high resiliency system pool
US8996700B2 (en) 2011-09-29 2015-03-31 International Business Machines Corporation Automated workload performance and availability optimization based on hardware affinity
US8943504B2 (en) * 2012-04-20 2015-01-27 Qualcomm Incorporated Tracking and releasing resources placed on a deferred unlock list at the end of a transaction
US9563871B2 (en) 2013-04-24 2017-02-07 Mastercard International Incorporated Systems and methods for storing computer infrastructure inventory data
US9544192B2 (en) 2013-04-24 2017-01-10 Mastercard International Incorporated Systems and methods for using metadata to search for related computer infrastructure components
US9619778B2 (en) 2013-04-24 2017-04-11 Mastercard International Incorporated Systems and methods for scanning infrastructure for inventory data
US9934002B2 (en) * 2013-10-30 2018-04-03 Entit Software Llc Technology recommendation for software environment
CN104484218B (zh) 2014-11-18 2017-11-17 华为技术有限公司 一种虚拟机名称展示的方法、装置及系统
US10725890B1 (en) 2017-07-12 2020-07-28 Amazon Technologies, Inc. Program testing service

Family Cites Families (65)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05346910A (ja) * 1992-06-15 1993-12-27 Nippon Telegr & Teleph Corp <Ntt> 資源均等分配方式
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
US7464147B1 (en) 1999-11-10 2008-12-09 International Business Machines Corporation Managing a cluster of networked resources and resource groups using rule - base constraints in a scalable clustering environment
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
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
US7467383B2 (en) * 2004-03-08 2008-12-16 Ab Initio Software Llc System for controlling task execution using a graphical representation of task dependency
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
JP2007011823A (ja) * 2005-07-01 2007-01-18 Yokogawa Electric Corp 分散コンピューティング環境における管理システム
US8219917B2 (en) * 2005-07-26 2012-07-10 International Business Machines Corporation Bubbling up task severity indicators within a hierarchical tree control
JP4940613B2 (ja) * 2005-09-29 2012-05-30 日本電気株式会社 制約条件に基づいた資源選択システム、資源選択方法および資源選択プログラム
US20070136725A1 (en) 2005-12-12 2007-06-14 International Business Machines Corporation System and method for optimized preemption and reservation of software locks
US7496893B2 (en) * 2006-06-15 2009-02-24 International Business Machines Corporation Method for no-demand composition and teardown of service infrastructure
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
JP4751265B2 (ja) * 2006-08-01 2011-08-17 株式会社日立製作所 リソース管理システム及びその方法
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
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
JP4848392B2 (ja) * 2007-05-29 2011-12-28 ヒューレット−パッカード デベロップメント カンパニー エル．ピー． コンピュータ構成におけるホットプラグのデバイスのクリティカリティを求める方法及びシステム
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
US8762211B2 (en) 2007-10-03 2014-06-24 Mastercard International Incorporated System for personalized payments via mobile devices
US8196142B2 (en) 2007-12-18 2012-06-05 Oracle America, Inc. Use of external services with clusters
JP5239072B2 (ja) * 2008-01-18 2013-07-17 インターナショナル・ビジネス・マシーンズ・コーポレーション 構成要素を管理するためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラム
WO2009096971A1 (en) * 2008-01-31 2009-08-06 Cluster Resources, Inc. System and method for managing a hybrid compute environment
WO2009110616A1 (ja) * 2008-03-07 2009-09-11 日本電気株式会社 仮想マシンパッケージ生成システム、仮想マシンパッケージ生成方法および仮想マシンパッケージ生成プログラム
GB0811943D0 (en) 2008-06-30 2008-07-30 Symbian Software Ltd Computing device
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
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
KR101277274B1 (ko) * 2009-11-27 2013-06-20 한국전자통신연구원 자원 간의 물리적/논리적 관계를 맵핑하는 방법 및 장치
US8375175B2 (en) 2009-12-09 2013-02-12 Oracle America, Inc. Fast and efficient reacquisition of locks for transactional memory systems
US9152523B2 (en) 2010-09-15 2015-10-06 Qualcomm Incorporated Batching and forking 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
US8806502B2 (en) 2010-09-15 2014-08-12 Qualcomm Incorporated Batching resource requests in a portable computing device
US8631414B2 (en) 2010-09-15 2014-01-14 Qualcomm Incorporated Distributed resource management in a portable computing device
US8694981B2 (en) * 2010-11-17 2014-04-08 Apple Inc. Shared resource dependencies

Also Published As

Publication number Publication date
JP2013537340A (ja) 2013-09-30
US8615755B2 (en) 2013-12-24
EP2616941A1 (en) 2013-07-24
US20120066391A1 (en) 2012-03-15
WO2012036776A1 (en) 2012-03-22
CN103098033A (zh) 2013-05-08

Similar Documents

Publication Publication Date Title
KR20130084659A (ko) 휴대형 컴퓨팅 디바이스의 리소스들을 관리하기 위한 시스템 및 방법
US8601484B2 (en) System and method for managing resources and markers of a portable computing device
KR101618476B1 (ko) 휴대용 컴퓨팅 디바이스에서 분산 리소스 관리
US8806502B2 (en) Batching resource requests in a portable computing device
KR101503209B1 (ko) 휴대용 컴퓨팅 디바이스의 스위치 패브릭들 내에서 그리고 스위치 패브릭들에 걸쳐 마스터-슬레이브 쌍들을 동적으로 생성하고 서비스하는 방법 및 시스템
US9098521B2 (en) System and method for managing resources and threshsold events of a multicore portable computing device
US9152523B2 (en) Batching and forking resource requests in a portable computing device
JP2013516711A (ja) 電子デバイスにおける電力を制御するシステムおよび方法
US9122730B2 (en) Free-text search for integrating management of applications
EP2751687B1 (en) Method and system for managing parallel resource requests in a portable computing device
EP2788873A1 (en) Batching of resource requests into a transaction and forking of this transaction in a portable computing device

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application