KR20000076691A - 복수의 오퍼레이팅 시스템을 실행하는 계산기 - Google Patents

복수의 오퍼레이팅 시스템을 실행하는 계산기 Download PDF

Info

Publication number
KR20000076691A
KR20000076691A KR1020000007733A KR20000007733A KR20000076691A KR 20000076691 A KR20000076691 A KR 20000076691A KR 1020000007733 A KR1020000007733 A KR 1020000007733A KR 20000007733 A KR20000007733 A KR 20000007733A KR 20000076691 A KR20000076691 A KR 20000076691A
Authority
KR
South Korea
Prior art keywords
priority
operating system
interrupt
task
operating systems
Prior art date
Application number
KR1020000007733A
Other languages
English (en)
Other versions
KR100759280B1 (ko
Inventor
사이토마사히코
카미와키타다시
나카무라토모아키
오오노히로시
이노우에타로
Original Assignee
가나이 쓰토무
가부시키가이샤 히타치세이사쿠쇼
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 가나이 쓰토무, 가부시키가이샤 히타치세이사쿠쇼 filed Critical 가나이 쓰토무
Publication of KR20000076691A publication Critical patent/KR20000076691A/ko
Application granted granted Critical
Publication of KR100759280B1 publication Critical patent/KR100759280B1/ko

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Executing Machine-Instructions (AREA)
  • Hardware Redundancy (AREA)
  • Multi Processors (AREA)
  • Document Processing Apparatus (AREA)

Abstract

복수의 오퍼레이팅 시스템을 갖고, 각각의 오퍼레이팅 시스템 상에서 실행되는 태스크의 중요성을 고려하여, 동작시켜야 되는 오퍼레이팅 시스템을 전환하는 시스템을 제공한다. 복수의 프로세스 또는 스레드에 할당된 우선순위에 따라서 실행하는 복수개의 오퍼레이팅 시스템은 각각이 실행하고 있는 프로세스 또는 스레드의 우선순위를 통지하는 우선순위 통지처리를 갖고, 각각의 오퍼레이팅 시스템으로부터 통지된 우선순위를 계산기 내에서 공통의 우선순위(정규화 우선순위)로 변환하는 우선순위 변환처리와, 우선순위 변환처리에 의해서 얻어진 정규화 우선순위를 비교하여, 보다 높은 정규화 우선순위를 가진 오퍼레이팅 시스템을 우선적으로 실행시키는 우선순위 비교처리를 실행한다.

Description

복수의 오퍼레이팅 시스템을 실행하는 계산기{COMPUTER FOR EXECUTING MULTIPLE OPERATING SYSTEMS}
본 발명은 복수개의 오퍼레이팅 시스템을 전환하면서 동작시키는 계산기 및 그 오퍼레이팅 시스템 전환방식을 대상분야로 하고, 특히, 상이한 우선순위 체계를 가진 오퍼레이팅 시스템의 전환방식에 관한 것이다.
하나의 계산기로 복수의 오퍼레이팅 시스템을 동작시키는 기술로서, 종래부터 대형계산기에 있어서, 「가상 계산기(Virtual Machine : VM)」가 알려져 있다. 해당 종래기술에서는, 계산기 내에서 병행하여 동작하는 복수개의 가상 계산기 각각의 위에서 복수의 사용자 태스크(user task)(이후, 프로세스 및 스레드(thread)를 통일하여 태스크라고 부른다)를 전환하여 처리를 실행한다. 가상 계산기는, 통상, 대형 계산기 내의 하나의 프로세스로서 실현되지만, 가상 계산기와 사용자 태스크와의 관련을 고려하면, 하나의 오퍼레이팅 시스템이라고 간주하는 것도 가능하다.
일반적으로, 각각의 가상 계산기에는, 해당 가상 계산기의 우선순위에 따라서 일정한 타임 슬라이스(time slice)(CPU 할당시간)를 준다. 각 가상 계산기는, 주어진 타임 슬라이스의 범위 내에서 사용자 태스크를 전환하여 동작시킨다. 이러한 가상 계산기 기술의 실행효율을 높이는 기술로서, 일본국 특개평 5-197577호에 개시된 「가상 계산기에 있어서의 가상 계산기 실행 우선순위 제어방식」이 있다.
해당 종래기술은, 복수의 가상 계산기와, 해당 복수의 가상 계산기를 제어하기 위한 가상 계산기 모니터로 구성된다. 가상 계산기는, 시스템 태스크와 같이 실행 우선순위가 높은 태스크의 실행개시·실행종료시에, 가상 계산기 모니터에 대하여 태스크의 우선순위를 통지한다. 이것을 받은 가상 계산기 모니터는, 가상 계산기의 실행 우선순위를, 통지된 우선순위로 변경한다. 가상 계산기의 실행 우선순위를 가상 계산기 내에서 실행되는 태스크의 우선순위로 변경함으로써, 가상 계산기 제어를 효율적으로 행할 수 있다.
마이크로프로세서, 특히, 조립용 마이크로프로세서의 성능향상과, 오퍼레이팅 시스템의 기능향상에 따라, 복수개의 상위한 오퍼레이팅 시스템을 하나의 계산기 상에서 동시에 동작시키고, 이들을 동적으로 전환하여 처리를 행하라는 사용자 요구가 나타나고 있다.
일반적으로, 공장·플랜트(plant) 등의 기계제어, 차재(車載) 네비게이션 시스템(navigation system)이라고 한 분야에서는, 외부 환경 변화에 대하여 바로 응답하라는 실시간성, 장시간 연속 운전을 가능하게 하는 신뢰성 등이 중요시되어 있다. 이 때문에, 인터럽트 응답성이 높고, 또한, 조밀한 모듈구성을 가진 실시간용 오퍼레이팅 시스템(실시간 OS)이 사용되는 것이 많다. 그렇지만, 실시간 OS는, 실시간성·신뢰성을 중요시하는 반면, 인간과의 인터페이스에 우수하다고는 말하기 어렵다.
한편, 일반의 퍼스널 컴퓨터(PC)에 사용하고 있는 사무처리용 오퍼레이팅 시스템(사무처리 OS)은, 화상을 사용하여 조작을 행할 수 있도록 하는 등, 대인간 인터페이스에 우수하다. 이 때문에, 종래는 실시간 OS를 사용하고 있는 분야에도 사무처리 OS의 사용자 인터페이스를 사용하고 싶다고 하는 요구가 높아지고 있다. 그러나, 사무처리 OS는 인간과의 대화를 주된 처리로 하고 있기 때문에, 인터럽트 응답성보다도 처리의 스루풋을 중요시하고, 비교적 장시간 인터럽트 금지상태대로 처리를 실행하는 경우도 있다. 또한, 조밀한 구성을 가진 실시간 OS에 대하여, 신뢰성에 있어서 필적한다고는 말하기 어렵고, 24시간 연속운전 등에 적합하지 않다고 하는 측면도 있다.
그렇지만, 대형 계산기 상에서 복수의 가상 계산기(오퍼레이팅 시스템)를 병행하여 동작시키는 방식과 같이, 동일 계산기 상에서 사무처리 OS와 실시간 OS를 동작시키고, 필요에 따라 이것들의 오퍼레이팅 시스템을 전환할 수 있으면, 뛰어난 사용자 인터페이스와 실시간성·신뢰성을 양립시킬 수 있다. 마이크로프로세서의 성능향상을 고려하면, 복수의 오퍼레이팅 시스템을 하나의 계산기 상에서 동작시키는 것은, 대형 계산기에만 허용된 기술이 아니다.
이때, 각각의 오퍼레이팅 시스템의 중요성을 고려하면, 항상 실시간 OS를 우선적으로 동작시키고, 실시간 OS 상에서 실행시키는 태스크가 존재하지 않게 된 경우에만, 사무처리 OS를 동작시킨다고 하는 방법이 가장 단순한 오퍼레이팅 시스템 전환방식이다. 그렇지만, 각 오퍼레이팅 시스템 상에서 동작하는 개개의 태스크의 중요성이, 이와 같이(실시간 OS 상의 태스크는, 항상, 사무처리 OS 상의 태스크보다도 중요성이 높다고 하는 것과 같이)단순히 분리된다고는 한정하지 않는다.
도 27에 단순한 분리를 행할 수 없는 예를 나타낸다. 도 27은 차재 네비게이션 시스템의 구성예를 나타낸 것이다. 여기서는, 시스템을 간략화하고, 차재 네비게이션 시스템이, (1) 운전위치를 인식하는 위치인식 태스크(370), (2) 목표지점까지의 최단 경로를 도출하는 경로탐색 태스크(371), (3) 버튼·터치 패널 등으로부터의 입력을 처리하는 인터페이스 태스크(372), (4) 운전휴게 중에 기동하고 있었던 게임 태스크(373)라는 4개의 태스크로 구성되어 있다고 가정한다. 통상, 고속 응답성·신뢰성이 요청되는 위치인식 태스크·경로탐색 태스크는 실시간 OS 상에서 실행되고, 사용자 인터페이스에 뛰어난 사무처리 OS(110)에서는, 인터페이스 태스크·게임 태스크 등을 실행한다. 그렇지만, 일반적으로, 경로탐색은 대단히 계산량이 큰 처리이고, 수초 오더(order)의 계산시간을 요하는 경우도 있다. 상기에 나타낸 단순한 중요성의 분리를 행하면, 이 동안에, 인터페이스 태스크의 처리는 정지하고, 사용자가 아무리 버튼을 누르더라도 인식되지 않는다고 하는 문제가 발생한다.
도 27에 나타낸 차재 네비게이션 시스템에서는 인터페이스 태스크의 중요성이 높고, 이것이 실행가능상태로 이행한 경우에는, 사무처리 OS를 우선적으로 실행해야 한다. 그렇지만, 상기 종래기술 「가상 계산기에 있어서의 가상 계산기 실행 우선순위 제어방식」은, 각 가상 계산기(오퍼레이팅 시스템)의 기능이 동일한 것을 전제로 하고 있다. 일반적으로, 실시간 OS는 환경변화에 고속으로 응답하기 때문에, 사무처리 OS에 비하여 매우 많은 우선순위레벨을 갖는 경우가 많다. 또한, 극단적인 경우, 실시간 OS 상에서는, 우선순위의 「수치」가 작을 수록(O에 가깝다) 우선순위가 높고, 사무처리 OS 상에서는, 우선순위의 「수치」가 클수록 우선순위가 높다고 한 반대의 의미가 주어지는 경우도 있다. 이러한 경우, 가령 두 개의 오퍼레이팅 시스템으로부터 우선순위가 통지되더라도, 어느 것의 오퍼레이팅 시스템을 우선적으로 기동해야 좋은지 판단할 수 없게 된다. 이 때문에, 상기 종래기술에서는, 다른 기능을 가지는 사무처리 OS와 실시간 OS를 통일하여 관리하는 것은 불가능하다.
본 발명의 목적은, 복수의 상이한 오퍼레이팅 시스템을 하나의 계산기 상에서 동작시키는 멀티오퍼레이팅 시스템 제어장치에 있어서, 각 오퍼레이팅 시스템 상에서 실행되고 있는 태스크의 중요성을 고려하여, 동작시켜야 할 오퍼레이팅 시스템을 선택·전환하는 것이고, 이것에 의해서, 중요성이 있는 태스크가 우선적으로 실행되도록 하는 것이다.
도 1은 본 발명의 제 1 실시예에 있어서의 시스템 구성을 나타낸 도면이고,
도 2는 계산기의 하드웨어 구성을 나타낸 도면이며,
도 3은 인터럽트 레벨 마스크 기능을 장비하는 경우의 상태 레지스터를 나타낸 도면이고,
도 4는 개별 인터럽트 마스크 기능을 장비하는 경우의 상태 레지스터를 나타낸 도면이며,
도 5는 오퍼레이팅 시스템 내부구성을 상세히 나타낸 도면이고,
도 6은 오퍼레이팅 시스템 전환 프로그램 내부구성을 상세히 나타낸 제 1 도면이며,
도 7은 리스케줄러의 처리 플로우를 나타낸 도면이고,
도 8은 우선순위 변환모듈의 처리 플로우를 나타낸 도면이며,
도 9는 우선순위 비교모듈의 처리 플로우를 나타낸 도면이고,
도 10은 오퍼레이팅 시스템 전환 프로그램 내부구성을 상세히 나타낸 제 2 도면이며,
도 11은 OS 콘텍스트 전환모듈의 처리 플로우를 나타낸 도면이고,
도 12는 공통 인터럽트 핸들러의 처리 플로우를 나타낸 도면이며,
도 13은 인터럽트 핸들러의 처리 플로우를 나타낸 도면이고,
도 14는 우선순위 상승방식에 있어서의 로크 취득모듈의 처리 플로우를 나타낸 도면이며,
도 15는 우선순위 상승방식에 있어서의 로크 해방모듈의 처리 플로우를 나타낸 도면이고,
도 16은 우선순위 설정모듈 내부구성을 상세히 나타낸 도면이며,
도 17은 우선순위 변환모듈에 있어서의 우선순위 역변환기능의 처리 플로우를 나타낸 도면이고,
도 18은 우선순위 설정모듈의 처리 플로우를 나타낸 도면이며,
도 19는 우선순위 계승방식에 있어서의 로크 취득모듈의 처리 플로우를 나타낸 도면이고,
도 20은, 우선순위 계승방식에 있어서의 로크 해방모듈의 처리 플로우를 나타낸 도면이며,
도 21은 인터럽트 마스크 레벨 계산모듈 내부구성을 상세히 나타낸 도면이고,
도 22는 인터럽트 마스크 레벨 계산모듈의 처리 플로우를 나타낸 도면이며,
도 23은 본 발명의 제 2 실시예에 있어서의 시스템구성을 나타낸 도면이고,
도 24는 우선순위 감시모듈의 처리 플로우를 도시한 도면이며,
도 25는 우선순위 감시모듈을 기동하는 공통 인터럽트 핸들러의 처리 플로우를 나타낸 도면이고,
도 26은 본 발명의 제 3 실시예에 있어서의 시스템구성을 나타낸 도면이며,
도 27은 오퍼레이팅 시스템 사이에서의 태스크 분배예를 나타낸 도면이고,
도 28은 공통 인터럽트 핸들러의 다른 구성을 나타낸 도면이며,
도 29는 본 발명의 제 4 실시예에 있어서의 시스템 구성을 나타낸 도면이다.
*도면의 주요부분에 대한 부호의 설명*
100: 프로세서 101: 메모리
102: 입출력 제어장치 103: 프로세서 버스
104: 디스크장치 105: 디스플레이
106: 실시간 제어 네트워크 107: 인터럽트 신호선
상기 목적을 달성하기 위해서, 본 발명에서는, 복수의 태스크를 각각의 태스크에 할당된 우선순위에 따라서 실행하는 복수의 오퍼레이팅 시스템과, 이 복수의 오퍼레이팅 시스템을 전환하여 실행하는 계산기에 있어서, 하기에 나타내는 처리를 행한다.
(1) 각 오퍼레이팅 시스템이 실행하고 있는 태스크의 우선순위를 확인하는 우선순위 감시처리를 행한다. 또는, 각 오퍼레이팅 시스템 내에, 자기가 실행하고 있는 태스크의 우선순위를 통지하는 우선순위 통지처리를 행한다. 사무처리 OS, 실시간 OS에서는, 내부에 우선순위 통지처리를 추가하는 것이 불가능한 경우도 있다. 이때, 전자의 우선순위 감시처리를 행할 필요가 있다.
(2) 각 오퍼레이팅 시스템으로부터 입수한 실행중 태스크의 우선순위를, 각각의 오퍼레이팅 시스템에서 공통의 우선순위로 변환하는 우선순위 변환처리를 행한다(이후, 해당 공통의 우선순위의 것을 「정규화 우선순위」라고 부른다. ).
(3) 우선순위 변환처리에 의해서 얻어진 각 오퍼레이팅 시스템의 정규화 우선순위를 비교하여, 동작시켜야 될 오퍼레이팅 시스템을 결정하고, 또한, 오퍼레이팅 시스템의 전환을 실행하는 우선순위 비교처리를 행한다.
본 발명에 의하면, 우선순위 통지처리는 각 오퍼레이팅 시스템 내에 설정되고, 오퍼레이팅 시스템이 태스크 전환을 행할 때마다, 해당 태스크의 우선순위를 통지한다.
태스크 전환기능은 오퍼레이팅 시스템의 중핵을 구성하는 것이기 때문에, 시판되어 있는 오퍼레이팅 시스템 내에 우선순위 통지수단을 조립하는 것이 불가능한 경우도 많다. 그렇지만, 일반적으로, 오퍼레이팅 시스템은 실행중 태스크의 관리정보를 계산기의 메모리 상에 유지하고, 이 관리정보의 일부에 태스크의 실행 우선순위가 있다. 또한, 태스크 전환처리를 고속화하기 위해서, 현재 실행중의 태스크의 우선순위를 특정한 변수(우선순위 유지변수)에 격납해 두는 경우도 있다. 우선순위 감시처리는, 태스크 관리정보 또는 우선순위 유지변수를 판독하여, 각 오퍼레이팅 시스템이 실행하고 있는 태스크의 우선순위를 확인한다. 우선순위 감시처리는, 외부 인터럽트, 타이머 인터럽트 등의 타이밍으로 우선순위를 확인한다.
우선순위 변환처리는, 각 오퍼레이팅 시스템으로부터 입수한 실행중 태스크의 우선순위를, 계산기 내에서 공통의 정규화 우선순위로 변환한다. 이 때문에, 우선순위 변환처리는, 각 오퍼레이팅 시스템에 대응하는 우선순위 변환 테이블을 갖는 경우도 있다. 우선순위 변환 테이블은, 각 오퍼레이팅 시스템 고유의 우선순위로부터 정규화 우선순위를 추출하기 위한 대응표이다. 간단한 수식에 의해서 개개의 오퍼레이팅 시스템의 우선순위를 정규화 우선순위로 변환하는 것도 가능하지만, 고속이고 또한 유연한 오퍼레이팅 시스템 전환을 실행하기 위해서는, 우선순위 변환 테이블을 사용하는 것이 좋다. 예컨대, 우선순위 변환 테이블에 격납하는 정규화 우선순위의 값을 적절히 정함으로써, 개개의 오퍼레이팅 시스템으로부터 얻어지는 정규화 우선순위가 서로 같게 되지 않도록 변환을 행하는 것도 가능하다.
우선순위 비교처리는, 각 오퍼레이팅 시스템의 정규화 우선순위를 우선순위 변환처리로부터 입수하고, 현재 동작시키고 있는 오퍼레이팅 시스템보다 높은 정규화 우선순위를 가진 오퍼레이팅 시스템이 존재하면, 오퍼레이팅 시스템의 전환을 행한다.
(실시예)
본 발명의 실시예를 도면을 사용하여 설명한다.
도 1에 본 발명의 제 1 실시예에 있어서의 전체구성을 나타낸다. 통상, 계산기는, 프로세서(100), 메모리(101), 입출력제어장치(102), 디스크장치(104), 디스플레이(105) 등으로 구성된다. 프로세서(100), 메모리(101), 입출력 제어장치(102)는 프로세서버스(1O3)에 의해서 접속된다. 프로세서(100)는 복수개의 오퍼레이팅 시스템을 동작시키기 위한 마이크로프로세서이다. 메모리(101)는 오퍼레이팅 시스템인 사무처리 OS(110), 실시간 OS(111), 각 오퍼레이팅 시스템 상에서 동작하는 태스크(112∼117), 오퍼레이팅 시스템 전환 프로그램(118)을 기억한다. 이것들의 프로그램은 프로세서(10O)에 의해서 판독되어 실행된다.
입출력 제어장치(1O2)에는, 프로그램·데이터를 저장하기 위한 디스크장치(104), 화면표시용 디바이스인 디스플레이(105)가 접속된다. 또한, 공장·플랜트 제어용, 또는, 조립용 계산기를 실현하는 경우, 입출력 제어장치(1O2)에는, 실시간 제어 네트워크(106)가 접속되어 있다. 실시간 제어 네트워크(106)에는, 센서, 액츄에이터 등의 입출력기기가 접속된다. 또, 입출력 제어장치(1O2)에 접속되는 디스크장치(1O4), 디스플레이(1O5), 실시간 제어 네트워크(1O6)의 입출력장치(104∼1 O6) 중, 어느 것인가, 또는 모두는, 시스템 구성에 의해서 생략되는 경우도 있다. 입출력 제어장치(1O2)는, 인터럽트 신호선(1O7)에 의해서 프로세서(100)와 접속되어, 입출력 동작완료 등을 통지할 수 있다. 도 1 중에서는, 설명을 위해, 인터럽트 신호선(1O7)과 프로세서 버스(103)가 별도의 장치인 것처럼 기재하고 있지만, 실제로는, 인터럽트 신호선(107)은 프로세서 버스(1O3)의 일부이다. 프로세서(100) 내부에는 타이머 장치(108)가 설치되어 있고, 일정 주기마다 내부 인터럽트를 발생시킨다. 타이머 장치(1O8)로부터의 인터럽트는, 오퍼레이팅 시스템의 시간을 재는 것 등에 사용된다.
프로세서(100)는 인터럽트 신호선(107)에 의해서 통지되는 외부 인터럽트나 타이머 장치(108) 등으로부터의 내부 인터럽트를 마스크할 수 있는 기능을 장비한다. 인터럽트 마스크란, 프로그램이 인터럽트 마스크를 해제할 때까지, 특정한 인터럽트가 들어가는 것을 지연시키는 기능이다. 일반적으로, 인터럽트 마스크 기능에는, 하기의 3종류가 존재한다.
(1) 전 인터럽트 마스크 : 모든 인터럽트를 마스크한다.
(2) 개별 인터럽트 마스크 : 개개의 인터럽트를 각각 마스크할 수 있도록 한다.
(3) 인터럽트 레벨 마스크 : 각 인터럽트에 레벨을 설정하고, 지정레벨 이하의 인터럽트를 마스크한다.
프로세서(100)의 종류에 의해서, 상기 (1) (2)의 조합, 또는, (1) (3)의 조합 중 어느 것인가로 구성하는 경우가 많다. 후자의 조합으로 구성하는 프로세서를 채용하는 경우, 대응하는 입출력장치의 중요성에 따라서 인터럽트 레벨을 할당하게 된다. 예컨대, 실시간 제어 네트워크(106)로부터의 인터럽트를, 디스크장치(1O4), 디스플레이(105)등으로부터의 인터럽트보다 높은 레벨로 설정한다.
본 실시예에서는, 계산기 내에 두 개의 오퍼레이팅 시스템인 사무처리 OS(110), 실시간 OS(111)가 존재한다. 이 오퍼레이팅 시스템은, 각자에게 할당된 메모리·프로세서 자원을 이용하여, 각각, 태스크(112∼114), 태스크(115∼117)를 실행시킨다. 여기서는, 오퍼레이팅 시스템수가 2개, 태스크수가 6개(각 오퍼레이팅 시스템에 대하여 3개씩)의 예를 나타내고 있지만, 이것들의 수치보다도 많은, 또는, 적은 오퍼레이팅 시스템, 태스크를 실장하는 것도 가능하다. 본 실시예에서는, 오퍼레이팅 시스템 수의 동적인 변경은 상정하지 않지만, 각 오퍼레이팅 시스템이 동적으로 태스크 생성·삭제를 행하는 것은 가능하다. 또한, 본 실시예에서는, 사무처리 OS(11O), 실시간 OS(111)에 관해서 설명하지만, 실제로, 각 오퍼레이팅 시스템이 어떤 종류라도, 본 발명에서 서술하는 기술은 적용 가능하다. 태스크(112∼114)는 사무처리 OS에서 실행되는 사무처리 태스크이며, 태스크(115∼117)는 실시간 OS에서 실행되는 실시간 태스크이다. 사무처리 OS(11O)와 실시간 OS(111)는, 각각 독립적으로 태스크의 우선순위를 정의하고 있다. 도 1에 나타내는 실시예에서는, 사무처리 OS(11O) 환경하에서, 태스크(112∼114)가 각각 우선순위 0, 7, 31을 갖고, 실시간 OS(111) 환경하에서, 태스크(115∼117)가 각각 우선순위 0, 99, 255를 갖는다. 한편, 본 실시예에 있어서 태스크란 프로세스 또는 스레드의 총칭을 의미한다. 프로세스란, 개별의 메모리 공간을 가지고 동작하는 프로그램을 의미한다. 이 때문에, 통상 어떤 프로세스는 별도의 프로세스의 데이터를 변경하는 것은 불가능하다. 스레드란, 프로세스의 메모리 공간을 공유하여 동작하는 프로그램을 가리킨다. 따라서, 동일 프로세스 내에서 동작하는 스레드끼리의 사이에서는 데이터 보호기능은 존재하지 않는다.
각 오퍼레이팅 시스템 내에는, 우선순위 통지모듈(120, 121)이 존재한다. 우선순위 통지모듈(12O, 121)은 각 오퍼레이팅 시스템의 태스크 전환시에 실행되고, 오퍼레이팅 시스템 전환 프로그램(118)에 대하여 다음에 실행해야 할 태스크의 우선순위를 통지한다.
일반적으로, 사무처리 OS와 실시간 OS는 다른 우선순위 체계를 갖는 경우가 많다. 실시간 OS에서는, 비교적 많은 우선순위 레벨을 가지는 것에 의해, 중요한 인터럽트에 대한 고속 응답성을 실현한다. 한편, 사무처리 OS에서는, 비교적 적은 우선순위 레벨을 사용하여, 스루풋을 향상시키는 방식을 채용한다. 또한, 오퍼레이팅 시스템의 종류에 의해서는, 우선순위의 수치가 작을 수록(0에 가깝다) 우선순위가 높은 경우와, 우선순위의 수치가 클수록 우선순위가 높은 경우가 있다. 이 때문에, 우선순위 통지모듈(12O, 121)로부터 얻어진 우선순위를 그대로 비교하더라도 의미가 없다. 또, 이후, 사무처리 OS(11O)에서는, 우선순위의 수치가 클수록 태스크의 우선순위가 높고(도 1 중에서는, 태스크(114)가 가장 우선된다), 실시간 OS(111)에서는, 반대로, 우선순위의 수치가 작을수록 태스크의 우선순위가 높은 (도 1 중에서는, 태스크(115)가 가장 우선된다) 것으로 하여 설명한다. 또한, 사무처리 OS(110)에 있어서의 우선순위는 0∼31의 범위로 지정할 수 있고, 실시간 OS(111)에 있어서의 우선순위는 0∼255의 범위로 지정할 수 있는 것으로 한다.
두 개의 오퍼레이팅 시스템에 있어서의 우선순위 체계의 차이를 해소하기 위해서, 오퍼레이팅 시스템 전환 프로그램(118)은, 우선순위 변환모듈(122,123), 우선순위 비교모듈(124)을 구성요소로서 갖는다. 우선순위 변환모듈(122,123)은, 각각 사무처리 OS(110), 실시간 OS(111)로부터 얻어진 우선순위를 시스템 내에서 공통의 비교기준인 정규화 우선순위로 변환한다. 각 오퍼레이팅 시스템의 우선순위를 그대로 비교하는 것은 불가능하지만, 일단 양자를 정규화 우선순위로 변환하면, 양 오퍼레이팅 시스템이 실행하고 있는 태스크의 우선순위를 비교할 수 있다. 또, 여기서, 정규화 우선순위가 한편의 오퍼레이팅 시스템의 우선순위와 완전히 동일해도 좋다. 이 경우, 해당 오퍼레이팅 시스템의 우선순위가 그대로 정규화 우선순위로 된다. 우선순위 비교모듈(124)은 양 오퍼레이팅 시스템으로부터 얻어진 정규화 우선순위를 비교하고, 또한 보다 높은 정규화우선순위를 가지는 오퍼레이팅 시스템으로 전환하여 실행시키는 역할을 한다.
도 2에, 프로세서(100)의 내부 구성예를 나타낸다. 캐시 메모리(131)는 메모리(101) 상의 데이터 또는 명령을 일시적으로 격납하는 버퍼기억장치이다.
CPU(13O)는 연산회로이며, 메모리(101) 또는 캐시 메모리(131) 상에 존재하는 명령을 순차 판독하여 실행한다. 명령실행에 있어서, 연산결과를 일시적으로 유지하기 위한 범용 레지스터(132), 명령 어드레스를 지정하는 프로그램 카운터(131), 실행상태를 유지하는 상태 레지스터(134)를 사용한다. CPU(13O), 캐시 메모리(131), 범용 레지스터(132), 프로그램 카운터(133), 상태 레지스터(134)는, 서로 데이터 전송을 행하는 복수의 신호선인 데이터 버스(136), 어드레스를 지정하는 복수의 신호선인 어드레스 버스(137)에 의해서 접속되어 있다.
인터럽트 신호선(1O7)과 타이머 장치(1O8)는 인터럽트 제어기(135)에 접속된다. 인터럽트 제어기(135)는, CPU(13O)에 대하여 인터럽트 상태신호(138)를 생성하는 역할을 한다. 인터럽트 상태신호(138)는, 프로세서(100)에 대하여 현재 어떠한 종류의 인터럽트가 발생하고 있는가를 나타내는 신호이다. 통상, 상태 레지스터(134)는 현재의 인터럽트 마스크에 관한 정보를 가지고 있고, 인터럽트 상태신호(138)로 지정되는 인터럽트를 접수하는지 아닌지를 결정한다. 인터럽트를 접수하는 경우, 인터럽트 제어기(135)는, 프로그램 카운터(133), 상태 레지스터(134) 등의 값을 갱신하고, 대응하는 인터럽트 처리 프로그램을 실행시킨다.
상태 레지스터(134)의 구성을 도 3에 나타낸다. 여기서는, 프로세서(10O)가 전 인터럽트 마스크 기능과 인터럽트 레벨 마스크 기능을 장비하고 있는 경우를 나타내고 있다. 도 3에서는, 상태 레지스터(134)가 인터럽트 블록 비트(140)와 인터럽트 마스크 레벨 필드(141)를 갖는다. 인터럽트 블록 비트(14O)가 ON인 경우, 프로세서(100)에 대한 모든 인터럽트가 마스크된다. 인터럽트 마스크 레벨 필드(141)는 현재의 인터럽트 마스크 레벨값을 나타내고, 이것 이하의 인터럽트 레벨은 접수되지 않는다. 도 3에서는, 인터럽트 마스크 레벨 필드(141)는 4비트 길이이다. 이 때문에, 합계 16종류의 마스크 레벨을 지정가능하지만(통상, 인터럽트 레벨 0은 「인터럽트가 발생하고 있지 않다」것을 의미하고, 인터럽트 마스크 레벨을 0으로 하는 것은 「인터럽트 마스크를 행하지 않는다」것을 의미하기 때문에, 실질적으로는 15종류로 되고, 인터럽트 마스크 레벨 필드(141)의 비트 수를 변경함으로써, 수리할 수 있는 인터럽트 레벨의 종류를 증감시킬 수 있다.
도 4는, 프로세서(10O)가 전 인터럽트 마스크 기능과 개별 인터럽트 마스크 기능을 장비하고 있는 경우의 상태 레지스터(134)의 구성을 나타낸 것이다. 이 예에서는, 상태 레지스터(134)는 실제로는 두 개의 레지스터(실행 상태 레지스터(142)와 인터럽트 마스크 레지스터(143))로 구성되다. 도 3과 같이 실행 상태 레지스터(142) 내에 인터럽트 블록 비트(140)가 설치된다. 인터럽트 마스크 레지스터(143) 내의 인터럽트 마스크 비트(144∼147)는 각각 개개의 인터럽트에 대응하고 있고, 이 인터럽트 마스크 비트 중 어느 것인가를 ON으로 한 경우, 대응하는 인터럽트가 접수되지 않게 된다. 도 3에 나타내는 상태 레지스터는, 도 4의 상태 레지스터의 특수한 것이다. 예컨대, 인터럽트 마스크 비트(144)만 ON으로 되어 있는 상태를 레벨 1로 하고, 인터럽트 마스크 비트(144, 145)의 두 개가 ON으로 되어 있는 상태를 레벨 2, 인터럽트 마스크 비트(144∼146)의 세 개가 ON으로 되어 있는 상태를 레벨 3,…,와 같이 대응시킬 수 있다. 이 때문에, 이후, 상태 레지스터(134)는 도 4에 나타낸 구성으로서, 본 발명을 설명한다.
일반적인 프로세서에서는, 인터럽트를 수리하면, 하드웨어에 의해서 자동적으로 인터럽트 블록 비트(14O)가 ON으로 갱신되고, 프로그램 카운터(133)에 인터럽트 처리 프로그램의 어드레스가 격납된다. 필요에 따라서, 인터럽트 처리 프로그램이 인터럽트 블록 비트(14O)를 OFF로 갱신하여 인터럽트 접수를 허가할 수 있다. 또한, 오퍼레이팅 시스템 및 태스크가, 일시적으로 인터럽트 블록 비트(140)나 인터럽트 마스크 레지스터(143)의 내용을 갱신하고, 특정 인터럽트의 접수를 기다리게 하는 것도 가능하다. 인터럽트 마스크 기능은, 배타 제어의 실현이나, 인터럽트 처리 실행 중에 다시 동일 인터럽트가 발생하는 것을 피하기 위해서 사용된다.
다음에, 이러한 하드웨어 상에 실현되는 본 발명의 소프트웨어 구성에 관해서 설명한다. 도 5에, 사무처리 OS(110), 실시간 OS(111)의 내부구성을 나타내었다. 도면 중, 모든 구성소자는 메모리(101) 상에 격납되어 있다.
사무처리 OS, 실시간 OS도, 실행 가능 태스크의 정보를 대기행렬(150, 151)의 형태로 관리한다. 실행가능 대기행렬(150, 151)은 우선순위마다 설치되는 경우도 있지만, 본 실시예에서는, 모든 실행 가능한 태스크가 하나의 대기행렬에 의해서 관리된다. 또, 실행가능 대기행렬이 한 개만, 우선순위마다 설치되더라도, 본 발명의 내용에는 영향을 주지 않는다. 각 태스크는, (a) 실행상태, (b)실행가능상태, (c) 대기상태의 3종의 상태를 순차 취하기 때문에 오퍼레이팅 시스템은, 실행가능 태스크 이외에, 대기상태 태스크, 정지상태 태스크 등을 별도의 대기행렬로 관리한다. 한편, 도 5에서는 이것들의 대기행렬의 기재를 생략하고 있다. 실행가능 대기행렬(150 및 151)에 의해서 관리되는 태스크 관리 테이블(160∼165)은, 실행해야 할 태스크의 우선순위, 태스크 실행시의 프로그램 카운터·상태 레지스터·범용 레지스터의 값 등을 저장한다.
실행가능 태스크를 하나의 대기행렬로 관리하는 경우, 실행가능 대기행렬에 등록되는 태스크 관리 테이블은 우선순위가 높은 순차로 배치된다. 즉, 다음에 실행해야 할 태스크의 관리 테이블이 대기행렬의 선두에 오도록 구성한다. 상술한 바와 같이, 본 실시예에서 서술하는 사무처리 OS(110)는, O∼31까지의 우선순위를 갖고, 우선순위의 수치가 클수록 우선순위가 높다. 또한, 실시간 OS(111)은, O∼255까지의 우선순위를 갖고, 우선순위의 수치가 작을수록 우선순위가 높다. 이 때문에, 사무처리 OS에서는, 태스크(114)(우선순위「31」)에 대응하는 관리 테이블(162)이 실행가능 대기행렬(15O)의 선두에 배치되고, 이하, 태스크(113)(우선순위「7」)의 관리 테이블(161), 태스크(112)(우선순위「O」)의 관리 테이블(16O)의 순으로 배치된다. 반대로, 실시간 OS에서는, 태스크(115)(우선순위「O」)에 대응하는 관리 테이블(163)이 실행가능 대기행렬(151)의 선두에 배치되고, 다음에, 태스크(116)(우선순위「99」)의 관리테이블(164), 태스크(117)(우선순위「255」)의 관리 테이블(165)의 순으로 배치된다.
각 오퍼레이팅 시스템은, 또한, 인터럽트 처리를 행하는 인터럽트 핸들러(interrupt handler)(152, 153), 태스크에 대하여 서비스를 제공하는 시스템 호출 프로그램(156, 157), 및, 태스크 전환을 행하는 리스케줄러(rescheduler)(154, 155)를 갖는다. 태스크의 생성·삭제·정지·재개나, 외부 인터럽트·내부 인터럽트 발생에 따라 태스크 전환을 행해야 하는 경우, 리스케줄러(154, 155)가 기동된다. 리스케줄러(154, 155)는, 직전에 실행하고 있었던 태스크의 실행환경(레지스터 등)을 태스크 관리 테이블에 격납한 후에 호출되고, 새롭게 실행해야 할 태스크를 결정하여, 그 실행환경을 태스크 관리 테이블로부터 추출한다.
이것을 프로그램 카운터, 상태 레지스터, 범용 레지스터 등에 설정함으로써, 선택한 태스크를 실행한다.
리스케줄러(154, 155)는 그 내부에 우선순위 통지모듈(120, 121)을 갖는다. 우선순위 통지모듈(120, 121)은, 새롭게 실행해야 할 태스크의 실행환경을 레지스터에 설정하기 직전에 기동되고, 태스크의 우선순위를 오퍼레이팅 시스템 전환 프로그램(118) 내의 우선순위 변환모듈(122, 123)에 통지한다.
도 6에는, 오퍼레이팅 시스템 전환 프로그램(118)의 내부구성을 나타낸 것이다. 우선순위 변환모듈(122, 123)은 각 오퍼레이팅 시스템에서의 우선순위를 정규화 우선순위로 변경하기 위해서, 우선순위 변환 테이블(17O, 171)을 각각 소유한다. 정규화 우선순위는, 본 실시예에서는, O∼255의 범위의 정수이며, 「정규화 우선순위의 수치가 클수록, 정규화 우선순위가 높다」라고 정의한다. 물론, 정규화 우선순위의 수치의 범위를 변경하거나, 「정규화 우선순위의 수치가 작을수록, 정규화 우선순위가 높다」라고 정의하는 것도 가능하다.
상술한 바와 같이, 사무처리 OS(110)는 O∼31까지의 우선순위를 가지고 있다. 이때, 우선순위 변환 테이블(17O)은, 32개의 엔트리를 가진 배열로 된다. 각 배열요소는 0∼255의 범위의 정수를 갖고, 또한, 이하의 부등식을 만족한다(여기서는, 배열의 명칭을 prioBusiness로 한다).
i 〉 j ⇔ prioBusiness [i] 〉 prioBusiness [j]
(단, 0i, j31)
사무처리 OS(110)의 우선순위, 및 정규화 우선순위는 다 같이, 수치가 클수록 우선순위가 높다라고 하고 있기 때문에, 이 조건이 성립할 필요가 있다.
마찬가지로, 실시간 OS(111)가 0∼255까지의 우선순위를 가지고 있는 경우, 우선순위 변환 테이블(171)은, 256개의 엔트리를 가지는 배열로 된다. 각 배열요소는 0∼255의 범위의 정수를 갖고, 또한, 이하의 부등식을 만족한다(배열의 명칭을 prioRealtime으로 한다).
i 〉 j ⇔ prioRealtime [i] 〈 prioRealtime [j]
(단, 0i, j255)
사무처리 OS와 부등호의 방향이 다른 이유는, 실시간 OS에서는, 우선순위의 수치가 작을수록 우선순위가 높다라고 하고 있기 때문이다.
도 6에서는, 사무처리 OS(110) 상에서 태스크(114)가 다음에 실행가능하다고 판정된 경우, 우선순위 통지모듈(120)로부터 우선순위의 수치「31」이 통지된다. 우선순위 변환모듈(122)은, 우선순위 변환 테이블(170)을 이용하고, 정규화 우선순위의 수치「124」를 입수할 수 있다. 반대로, 실시간 OS(111) 상에서 태스크(115)가 다음에 실행가능해진 경우, 우선순위 통지모듈(121)로부터 실시간 OS에서의 우선순위의 수치「O」가 통지된다.
우선순위 변환 모듈(123)은, 우선순위 변환 테이블(171)을 사용하여, 정규화 우선순위의 수치「255」를 입수한다. 여기서, 본 실시예에서는, 사무처리 OS(110)의 태스크의 우선순위가 아무리 높더라도, 정규화 우선순위의 수치가 「124」를 넘지 않는다는 것에 주의해야 한다. 이것은, 우선순위 변환 테이블의 설정방법의 극단적인 예이며, 실시간 OS 상의 태스크를 가능한 한 우선하여 실행시킨다고 하는 목적을 위한 것이다(실시간 OS상의 태스크에서도, 우선순위가 낮은 것에 대하여는, 사무처리 OS 상의 태스크가 우선하는 경우가 있다). 그러나, 물론, 두 개의 오퍼레이팅 시스템의 우선순위가 가능한 한 대등히 정규화 우선순위로 변환되도록, 우선순위 변환 테이블(170)의 구성을 변경하는 것도 가능하다.
우선순위 변환모듈(122,123)이 변환한 정규화 우선순위는 어느 것이나, 우선순위 비교모듈(124)에 통지된다. 우선순위 비교모듈(124)은, 통지된 사무처리 OS 정규화 우선순위(172)와 실시간 OS 정규화 우선순위(173)를 유지한다. 이 경우, 사무처리 OS 정규화 우선순위(172)의 수치는「124」이며, 실시간 OS 정규화 우선순위(173)의 수치는 「255」이다.
상술한 바와 같이, 우선순위 통지모듈(120, 121)은 리스케줄러 내에 존재하고, 태스크 전환시에 실행된다. 태스크 전환으로부터 다음 태스크 전환까지의 기간은 하나의 태스크밖에 실행되지 않기 때문에, 태스크의 우선순위가 동적으로 변화하지 않는 한, 이 동안에, 해당 오퍼레이팅 시스템에 대한 정규화 우선순위도 변화하지 않는다. 우선순위 통지모듈(120, 121)은 태스크 전환시에 반드시 우선순위를 통지하기 때문에, 우선순위 비교모듈(124) 내에 유지하고 있는 사무처리 OS 정규화 우선순위(172)와 실시간 OS 정규화 우선순위(173)가, 실제의 각 오퍼레이팅 시스템에서의 태스크의 우선순위를 반영한 수치로 된다.
우선순위 비교모듈(124)은, 유지하고 있는 각 오퍼레이팅 시스템의 정규화 우선순위(172, 173)의 수치를 서로 비교하여, 보다 높은 정규화 우선순위를 가지는 오퍼레이팅 시스템을 우선적으로 실행시킨다. 도 6의 예에서는, 보다 높은 정규화 우선순위를 가지는 실시간 OS(111)를 실행시키게 된다.
오퍼레이팅 시스템 전환 프로그램(118)은 우선순위 변환모듈(122, 123), 우선순위 비교모듈(124) 외에, 발생한 인터럽트를 각 오퍼레이팅 시스템에 분배하는 공통 인터럽트 핸들러(174), 오퍼레이팅 시스템 사이에서의 협조처리를 실행하는 OS간 통신 기능모듈(175), 두 개의 오퍼레이팅 시스템의 실행환경 전환을 행하는 OS 콘텍스트(context) 전환모듈(176), 태스크의 우선순위에 의해서 인터럽트 마스크를 변경하는 인터럽트 마스크 레벨 계산모듈(177)을 갖는다. 이 프로그램의 상세한 것은 후술한다.
도 7에 사무처리 OS(110)에 있어서의 리스케줄러(154)의 처리플로우를 나타내었다. 실시간 OS(111)의 리스케줄러(155)도 같은 처리를 행한다. 리스케줄러(154)는 일반적으로, (1) 타이머 인터럽트 처리 종료시, (2) 외부 인터럽트 처리 종료시, (3) 시스템 호출 실행시 등에 있어서, 현재 실행 중의 태스크가 실행 가능하지 않게 되지만, 실행중 태스크보다 높은 우선순위의 태스크가 실행 가능해진 경우, 실행중 태스크의 레지스터를 태스크 관리 테이블로 퇴피한 후에 기동되는 모듈이다. 리스케줄러(154)를 기동하는 가능성이 있는 시스템 호출에는, (a) 태스크의 생성·종료·정지·재개(예컨대, 자기보다 우선순위가 높은 태스크를 생성한 경우), (b) 배타제어의 실행·종료(배타제어 대기상태로 이행한 경우 등)에 덧붙여, (c) 태스크의 우선순위 변경(자기의 우선순위를 저하시킨 경우 등)이라고 한 것이 있다.
리스케줄러(154)는 첫째로 실행가능 대기행렬(150)로부터 최고 우선순위의 태스크 관리 테이블을 추출한다(처리 181). 여기서, 모든 태스크가 대기상태나 정지상태로 되어 있어, 실행가능 태스크가 존재하지 않는 경우도 있다. 이것을 처리 182로 판정한다.
실행가능 태스크가 존재하지 않으면, 우선순위 변환모듈(122)에 idle상태인 것을 통지한다(처리 184). 이때, 실행가능 태스크가 존재하지 않기 때문에, idle루프로 이행한다(처리 186). idle루프란, 실행해야 할 처리가 나타날 때까지 아무것도 행하지 않는 프로그램이다. 여기서 주의해야 할 것은, 처리 184에 있어서, 우선순위 변환모듈(122)에 대하여 idle상태를 통지한 것이다. 사무처리 OS(11O)가 idle상태이면, 우선순위 비교모듈(124)은 실시간 OS(111)를 우선하여 실행시킨다. 따라서, 양 오퍼레이팅 시스템이 동시에 idle상태로 이행한 경우를 제외하고, 실제로 처리 186에서 idle루프가 실행되는 일은 없다. 다시 사무처리 OS(11O)가 실행되는 경우에는, 무엇인가의 실행해야 할 처리가 존재하기 때문에, 즉시 idle루프를 빠져 처리 181로 이행하게 된다.
처리 182에서 실행해야 할 태스크가 존재한다고 판정한 경우, 다음에 실행해야 할 태스크의 우선순위를 태스크 관리 테이블로부터 추출하여, 우선순위 변환모듈(122)에 통지한다. 통지한 우선순위가 실시간 OS(111)의 우선순위보다도 낮은 경우(정규화 우선순위에 의한 비교), 이 시점에서, 실시간 OS(111)로 전환되게 된다. 실시간 OS(111)로부터 반대로 사무처리 OS(11O)로 전환이 행해지는 경우, 인터럽트 처리 등에 의해서, 실행하고자 하는 태스크가 실행가능하지 않게 되거나, 또 높은 우선순위의 태스크가 실행가능해지거나 하지 않은 한, 처리 183의 직후에서 재실행하게 된다(처리 181에서 선택한 태스크를 기동한다). 또, 당연한 일이지만, 현재 실행 중의 태스크가 실행가능하지 않게 되지만, 실행중 태스크보다 높은 우선순위의 태스크가 실행가능해진 경우에는, 리스케줄러(154) 자체가 재기동된다. 처리 185에서, 태스크 관리 테이블로부터 레지스터를 복귀하여 프로세서(100)의 레지스터에 등록함으로써, 선택한 태스크의 처리를 실행한다.
여기서, 리스케줄러(154) 중, 처리 183,184가 우선순위 통지모듈(120)에 해당한다. 리스케줄러(155) 내에도 마찬가지로 우선순위 통지모듈(121)이 매립된다.
다음에, 도 8에, 사무처리 OS(110)에 대응하는 우선순위 변환모듈(122)의 처리플로우를 나타낸다. 우선순위 변환모듈(122)은 우선순위 통지모듈(120)로부터 호출되어, 즉시, 우선순위 변환처리를 실행한다. 최초에, 우선순위 통지모듈(120)이 idle상태를 통지하여 왔는지 아닌지를 판정하는 (처리 19O). idle 상태는 모든 우선순위보다도 낮은 우선순위를 갖는다고 간주하는 것도 가능하기 때문에, 여기서는, 어느 쪽의 정규화 우선순위보다도 낮게 되도록, (-1)이라는 정규화 우선순위의 수치를 가지고 있다고 생각한다. 처리 193에서는, 이 수치(-1)를 우선순위 비교모듈(124)에 통지한다. idle상태가 아니면, 우선순위 변환 테이블(170)로부터 대응하는 엔트리를 판독하고(처리 191), 이것을 우선순위 비교모듈(124)에 통지한다(처리 192). 실시간 OS(111)에 대응하는 우선순위 변환모듈(123)의 처리도 마찬가지이다.
도 9는 우선순위 비교모듈(124)의 처리플로우이다. 우선순위 비교모듈(124)은, 첫째로, 사무처리 OS(11O)에서의 정규화 우선순위인지, 실시간 OS(111)로부터의 정규화 우선순위인지를 판정한다(처리 200). 사무처리 OS(110)의 정규화 우선순위이면, 사무처리 OS 정규화 우선순위(172)에 입수한 정규화 우선순위를 격납한다(처리201). 실시간 OS(111)으로부터의 정규화 우선순위이면, 실시간 OS 정규화 우선순위(173)에 해당 정규화 우선순위를 기억한다(처리 202).
정규화 우선순위가 통지되어 오는 것은, 어느 것인가 한 편의 정규화 우선순위가 변화되었을 가능성이 있는 경우만이기 때문에, 여기서, 사무처리 OS 정규화 우선순위(172)와 실시간 OS 정규화 우선순위(173)의 수치를 비교한다(처리 203). 본 실시예에서는, 정규화 우선순위의 수치가 큰 오퍼레이팅 시스템을 우선적으로 기동한다고 하고 있다. 따라서, 사무처리 OS(110)의 정규화 우선순위의 수치가 실시간 OS(111)의 정규화 우선순위의 수치보다 크면, 다음에 실행해야 할 오퍼레이팅 시스템을 사무처리 OS(110)로 한다(처리 204). 이 이외의 경우에는, 다음에 실시간 OS(111)를 실행시키는 것으로 한다(처리 205). 또, 여기서는, 사무처리 OS(110)와 실시간 OS(111)의 정규화 우선순위가 같더라도, 실시간 OS(111)를 실행시킨다. 이것을 변경하여, 정규화 우선순위가 서로 같은 경우에는 사무처리 OS(11O)를 실행시킨다고 해도 문제는 없다. 또한, 우선순위 변환 테이블(170, 171)의 내용을 설정하는 데에 있어서, 각 오퍼레이팅 시스템으로부터 얻어지는 정규화 우선순위가 서로 같게 되지 않도록 하는 것도, 시스템을 단순화시키기 위한 하나의 방법이다.
다음 처리 206에서, 새롭게 실행해야 할 오퍼레이팅 시스템이 지금까지 실행하고 있는 오퍼레이팅 시스템과 같은지 아니지를 판정한다. 지금까지와 다른 오퍼레이팅 시스템을 실행시키는 경우, OS 콘텍스트 전환모듈(176)에 의뢰하여, 오퍼레이팅 시스템 실행환경을 퇴피·복귀시킨다(처리 2O7).
도 10에 인터럽트 핸들러(152, 153), 공통 인터럽트 핸들러(174), OS간 통신 기능모듈(175), OS 콘텍스트 전환모듈(176)의 상세를 나타낸다(인터럽트 마스크 레벨 계산모듈(177)에 관해서는, 별도의 도면으로 상세히 설명한다).
인터럽트 핸들러(152, 153)는, 인터럽트 발생시의 레지스터 등의 보존, 일시변수의 유지를 행하기 위한 영역으로서, 각각 인터럽트 스택(214, 215)을 소유한다. 인터럽트 발생시에는, 인터럽트 발생 직전의 레지스터값을 저장하고, 이 레지스터값을 인터럽트 처리 종료후에 복귀해 주지 않으면 안된다. 이 때문에, 인터럽트 스택(214, 215)이 필요하게 된다. 사용하는 프로세서(1O0)의 종류에 의해서는, 인터럽트 발생시에 자동적으로 레지스터가 전환되고, 또한 인터럽트 처리 종료후에 전환 전의 레지스터로 되돌아가는 기능을 구비하고 있는 것도 있다. 그렇지만, 다중 인터럽트가 가능한 시스템을 고려한 경우에는, 이러한 하드웨어를 사용하고 있더라도, 인터럽트 스택이 필요하게 된다(인터럽트 처리중에 보다 높은 긴급성을 가지는 인터럽트가 발생한 경우, 새롭게 발생한 인터럽트 처리를 우선적으로 실행하고, 이어서, 원래의 인터럽트 처리로 되돌아가야 한다).
인터럽트 핸들러(152, 153)는, 더 인터럽트 스택(214, 215) 중, 어떤 영역까지 사용했는지를 나타내기 위한 포인터로서, 인터럽트 스택 포인터(216, 217)를 소유한다. 인터럽트 핸들러(152, 153)는 인터럽트 스택, 및, 인터럽트 스택 포인터를 사용하여 인터럽트 발생 전의 실행환경(레지스터 등)을 보존하고, 필요한 인터럽트 처리를 실행한다. 인터럽트 처리 종료후, 인터럽트 발생 전의 실행환경을 복귀하여 원래 동작하고 있는 프로그램의 실행을 계속시킨다.
공통 인터럽트 핸들러(174)는 발생한 인터럽트를 인터럽트 핸들러(152,153)에 대하여 분리하는 역할을 한다. 이 때문에, 공통 인터럽트 핸들러(174)는, 현재 실행하고 있는 오퍼레이팅 시스템이 사무처리 OS(110)인지 실시간 OS(111)인지를 기억하는 영역으로서, 실행 OS 기억변수(210)를 소유한다. 예컨대, 도 10에 나타낸 시점에서 사무처리 OS가 처리를 실행하고 있는 것이라고 가정하면 , 이 경우, 실행 OS 기억변수(210)에는, 「사무처리 OS」가 기억되어 있다. 물론, 실행 OS 기억변수(21O)가 문자열「사무처리 OS」를 기억하는 것은 대단히 비효율적이기 때문에, 예컨대,
· 사무처리 OS0
· 실시간 OS1
라고 한 정수형식으로 기억하면 좋다. 공통 인터럽트 핸들러(174)는, 더 발생한 인터럽트가 어느 쪽의 오퍼레이팅 시스템에 대응하는가를 나타내는 인터럽트 대응 테이블(211)을 갖는다. 인터럽트 대응 테이블(211)은 개개의 인터럽트가 어느 쪽의 오퍼레이팅 시스템으로 처리되어야 하는가를 나타내는 대응표이다. 본 실시예에서는, 도 4에 나타낸 바와 같이, 32 종류의 인터럽트 요인이 존재한다. 이 때문에, 인터럽트 대응 테이블(211)도 32개의 엔트리(O∼31)로 구성된다. 도 10의 예에서는, 인터럽트 요인 0이 사무처리 OS에서, 인터럽트 요인 1이 실시간 OS에서, …, 인터럽트 요인 31이 실시간 OS에서, 즉 어느 것인가의 오퍼레이팅 시스템에서 처리가 실행되어야 하는지가 정의되어 있다. 또, 효율상, 인터럽트 대응 테이블(211)의 내용도, 실행 OS 기억변수(210)와 같이, 문자열 형식이 아니라, 정수형식으로 기억해야 한다.
그런데, 계산기의 종류에 의해서는, 하나의 입출력기기를 두 개의 오퍼레이팅 시스템이 공용하는 경우도 있다(예컨대, 사무처리 OS(11O), 실시간 OS(111)의 양자가 디스플레이에 문자나 영상을 출력하는 경우). 이러한 시스템을 실현하기 위해서는, 인터럽트 분리 전의 오퍼레이팅 시스템을 동적으로 변경할 수 있는 것이 필요해진다. 본 실시예에서, 분리전 오퍼레이팅 시스템을 고정화하는 것이 아니라, 인터럽트 대응 테이블(211)로부터 입수하는 것은, 이 때문이다. 인터럽트 대응 테이블(211)의 내용을 입출력기기의 사용상황에 의해서 변경함으로써, 인터럽트의 분리전을 동적으로 변경할 수 있다.
공통 인터럽트 핸들러(174)는, 실행 OS 기억변수(210)를 사용하여 현재 실행하고 있는 오퍼레이팅 시스템의 종류를 판정하고, 이것이 인터럽트 대응 테이블(211)로부터 얻어진 분리전 오퍼레이팅 시스템과 일치하지 않으면, OS 콘텍스트 전환모듈(176)에 전환을 의뢰한다. 오퍼레이팅 시스템이 일치하는지, 오퍼레이팅 시스템 전환 종료후, 해당하는 오퍼레이팅 시스템의 인터럽트 핸들러에 처리를 의뢰한다. 또, 실행 OS 기억변수(210)는 OS 콘텍스트 전환모듈(176)로부터도 참조된다. 이와 같이, 오퍼레이팅 시스템 전환 프로그램(118) 내의 각 모듈이 가지는 내부구조는, 개개의 모듈에 의해서 점유되는 것이라고는 한정하지 않고, 각 모듈이 필요에 따라서 공용할 수 있다.
OS 콘텍스트 전환모듈(176)은, 우선순위 비교의 결과, 또는 인터럽트 발생의 결과, 오퍼레이팅 시스템을 변경해야 하는 경우에 기동된다. 두 개의 오퍼레이팅 시스템을 변경하기 위해서는, 이것들의 실행환경(즉, 레지스터값)을 보존해 두기 위한 영역을 소유해야 한다. 여기서는, 사무처리 OS의 실행환경을 보존하기 위한 영역으로서, 사무처리 OS용 보존 콘텍스트(212), 실시간 OS의 실행환경을 보존하기 위한 영역으로서, 실시간 OS용 보존 콘텍스트(213)를 준비한다.
OS 콘텍스트 전환모듈(176)은, 현재 실행하고 있는 오퍼레이팅 시스템에 대응하는 보존 콘텍스트에 실행환경을 보존하고, 다음에, 또 한 편의 보존 콘텍스트로부터 실행환경을 판독하여, 프로세서(100)의 레지스터에 설정한다. 이것에 의해, 오퍼레이팅 시스템의 전환을 실시할 수 있다.
OS간 통신 기능모듈(175)은 두 개의 오퍼레이팅 시스템 상의 태스크가 서로 통신·협조하기 위한 프로그램이다. 여기서는, 사무처리 OS(110), 실시간 OS(111)의 양자가 사용할 수 있는 공유 메모리(218), 및 오퍼레이팅 시스템 사이에서 배타제어를 행하기 위한 로크(lock) 취득모듈(219), 로크 해방모듈(220)이 존재하고 있다. 공유 메모리(218)는 메모리(101)의 일부이며, 양 오퍼레이팅 시스템으로부터 참조할 수 있는 영역이다. 공유 메모리(218) 이외의 메모리는, 기본적으로, 사무처리 OS용 영역, 실시간 OS용 영역, 오퍼레이팅 시스템 전환 프로그램용 영역으로 분할되고, 각각, 사무처리 OS(110), 실시간 OS(111), 오퍼레이팅 시스템 전환 프로그램(118)에 점유되어 사용된다. 두 개의 오퍼레이팅 시스템 상의 태스크가 공유 메모리(218)를 사용하는 경우, 통상, 배타 제어를 행하여 공유 메모리(218) 상의 데이터의 일관성을 유지한다. 애플리케이션 프로그램이 오퍼레이팅 시스템 사이에 걸치는 배타제어를 행하는 경우, 로크 취득모듈(219), 로크 해방모듈(220)이 제공하는 기능을 이용한다.
이때, 우선순위 역전현상이라고 불리는 상황에 관해서 주의해야 한다. 우선순위 역전현상이란, 일반적으로, 이하의 상태를 의미한다.
(1) 저우선순위인 태스크 α가 최초에 기동되어 로크를 취득한다.
(2) 다음에 고우선순위인 태스크 β가 기동되어 로크 대기상태로 이행한다.
(3) 다음에 중우선순위인 태스크 γ가 기동되어, 태스크 α(저우선순위)부터 태스크 γ(중우선순위)로의 전환이 행해진다.
이때, 태스크 γ의 실행에 의해서 태스크 α의 실행이 방해되고, 결과적으로, 고우선순위 태스크 β가 로크를 취득하기까지의 시간이 연장되어 버리게 된다.
우선순위 역전현상은, 통상, 우선순위 상승방식 또는 우선순위 계승방식을 사용하여 해결한다. 우선순위 상승방식은, 로크 취득을 행한 태스크의 우선순위를 일정한 레벨까지 높게 하는 방식이다. 이것에 의해서, 로크 취득을 행한 태스크 α의 우선순위가 일시적으로 태스크 γ(중우선순위)보다도 높아져, 태스크 γ가 기동되더라도, 로크 해방까지는 태스크 α가 실행된다. 이 후, 고우선순위인 태스크 β가 로크를 취득하여, 처리를 계속하게 된다.
우선순위 계승방식은, 상기 우선순위 상승방식을 변경하여 유연성을 갖게 한 것이다. 우선순위 계승방식에서는, 로크 대기상태로 이행한 태스크(예에서는, 태스크 β)의 우선순위가 로크를 취득하고 있는 태스크(태스크 α)보다도 높으면, 이 우선순위를 로크 취득 중 태스크에 계승시키는 방식이다. 여기서는, 로크 취득 중의 시간만, 태스크 α가 태스크 β의 우선순위를 계승하게 된다. 저우선순위의 태스크에서 배타제어를 행하는 경우 등, 반드시 우선순위를 일정 레벨까지 상승시킬 필요가 없는 경우도 있고, 우선순위 계승방식은, 이러한 상황에도 대처할 수 있는 방식이다.
본 실시예에서 서술하는 로크 취득모듈(219), 로크 해방모듈(220)은, 이와 같은 우선순위 상승 또는 우선순위 계승방식을 오퍼레이팅 시스템 사이에서 실시할 수 있는 것으로 한다. 오퍼레이팅 시스템 사이에서의 우선순위 상승·계승은, 정규화 우선순위를 사용하여 행해진다.
이후, 도 10에 나타낸 모듈 중, OS 콘텍스트 전환모듈(176), 공통 인터럽트 핸들러(174), 인터럽트 핸들러(152), 로크 취득모듈(219), 로크 해방모듈(220)의 처리플로우를 설명한다. 인터럽트 핸들러(153)에 관해서는, 인터럽트 핸들러(152)와 같은 처리플로우를 갖기 때문에, 설명을 생략한다.
도 11은 OS 콘텍스트 전환모듈(176)의 처리플로우이다. OS 콘텍스트 전환모듈(176)은, 오퍼레이팅 시스템을 변경해야 하는 경우에만 호출되고, 변경이 필요한지, 아닌지의 체크는 호출 전에 행해지고 있다. 따라서, 최초에, 어느 것의 오퍼레이팅 시스템으로 변경해야 하는지만을 체크한다(처리 23O). 여기서, 사무처리 OS(110)로부터 실시간 OS(111)로 변경하는 경우(현 실행 오퍼레이팅 시스템이 사무처리 OS(11O)에 있어서, 실시간 OS(111)의 우선순위가 높아진 경우), 사무처리 OS용 보존 콘텍스트(212) 내에 사용중 레지스터의 값을 퇴피한다(처리 231). 다음에, 실시간 OS용 보존 콘텍스트(213)로부터 실행환경을 복귀하여, 레지스터에 설정함으로써(처리 232), 이전 퇴피한 상태로부터 실시간 OS(111)를 재실행시킬 수 있다. 실시간 OS(111)로부터 사무처리 OS(110)로의 전환을 행하는 경우, 반대로, 실시간 OS용 보존 콘텍스트(213)로 사용중 레지스터의 값을 퇴피하고(처리 233), 다음에, 사무처리 OS용 보존 콘텍스트(212)로부터 레지스터를 복귀한다(처리234). 어느 쪽의 경우에 있어서도, 최후에, 전환후의 오퍼레이팅 시스템의 종류를 실행 OS 기억변수(210)에 기록한다(처리 235).
도 12에는, 공통 인터럽트 핸들러(174)의 처리 플로우를 나타내고 있다. 일반적으로, 단일의 오퍼레이팅 시스템에 의해서 제어되는 계산기에서는, 일단, 모든 인터럽트를 인터럽트 핸들러라고 불리는 모듈이 처리하고, 이어서, 각 프로그램으로 분배한다. 그렇지만, 본 실시예에서 설명하는 것과 같은 복수개의 오퍼레이팅 시스템을 동작시키는 계산기에서는, 이보다 전에, 공통 인터럽트 핸들러가 모든 인터럽트를 접수하고, 이것을 대응하는 오퍼레이팅 시스템의 인터럽트 핸들러로 분배는 형태로 이루어진다. 각 오퍼레이팅 시스템으로 인터럽트를 분배하는 것에 대응하여, 인터럽트 발생시에, 인터럽트 대상과는 별도의 오퍼레이팅 시스템이 처리를 실행하고 있는 경우도 있다. 이 경우, 인터럽트에 대응하는 오퍼레이팅 시스템으로 변경해야 하고, 공통 인터럽트 핸들러는 이러한 역할도 가지게 된다.
공통 인터럽트 핸들러(174)는, 인터럽트 발생후, 첫째로, 실행 OS 기억변수(21O)의 내용을 추출하여, 현재 실행중의 오퍼레이팅 시스템이 사무처리 0S(l1O) 인지 실시간 OS(111)인지를 체크한다(처리 240). 다음에, 인터럽트 대응 테이블(211)을 사용하여, 발생한 인터럽트가 어느 것의 오퍼레이팅 시스템에 대응하고 있는가를 입수한다(처리 241). 예컨대, 도 10의 인터럽트 대응 테이블(211)을 사용한다라고 하면, 인터럽트 「0」이 발생한 경우에는 사무처리 OS(110), 인터럽트 「1」이 발생한 경우에는 실시간 OS(111),…, 인터럽트 「31」이 발생한 경우에는 실시간 OS(111)라고 하도록 대응하는 오퍼레이팅 시스템을 입수할 수 있다. 여기서, 인터럽트 대상 오퍼레이팅 시스템이 실행중 오퍼레이팅 시스템과 같은지 아닌지를 체크한다(처리 242).
발생한 인터럽트가 현재 실행중의 오퍼레이팅 시스템에 대한 것이 아니면, 일단, 오퍼레이팅 시스템을 변경해야 한다. 이 변경처리는, OS 콘텍스트 전환모듈(176)에 의뢰함으로써 행한다(처리 243). 다음에 인터럽트 대상 오퍼레이팅 시스템이 사무처리 OS(11O)인지 실시간 OS(111)인지를 체크하고(처리 244), 대상이 사무처리 OS(11O)이면, 사무처리 OS의 인터럽트 핸들러(152)를 기동한다(처리 245). 실시간 OS(111)에 인터럽트가 발생하고 있으면, 실시간 OS의 인터럽트 핸들러(153)를 기동하게 된다(처리 246). 일반적으로, 인터럽트 핸들러(152,153)는, 인터럽트 처리에 의해서 태스크 전환을 행해야 할 때, 리스케줄러(154, 155)를 호출하고, 공통 인터럽트 핸들러(174)로 제어를 되돌리는 일은 없다. 그러나, 태스크 전환이 발생하지 않은 경우, 그대로 인터럽트 핸들러의 처리를 종료한다. 이때, 인터럽트 핸들러(152, 153)는, 공통 인터럽트 핸들러로 제어를 되돌리고(도13으로 후술), 공통 인터럽트 핸들러는 처리 247로부터 동작을 재개한다. 처리 247은, 인터럽트 발생시에 오퍼레이팅 시스템을 전환하는지 어떤지를 체크하는 처리이다. 처리 243에 의해서 오퍼레이팅 시스템을 전환한 경우, 여기서 다시, 오퍼레이팅 시스템을 전환하여, 원래의 실행환경으로 되돌릴 필요가 있다. 태스크 전환이 발생하지 않는다라고 하는 것은, 양 오퍼레이팅 시스템의 정규화 우선순위가 변화하지 않았다는 것을 의미하고, 인터럽트 발생 전의 실행상태로 되돌려야 하는 것이다. 이 때문에, 또 한번 OS 콘텍스트 전환모듈(176)에 의뢰하여, 전환처리를 실행시킨다(처리 248).
각 오퍼레이팅 시스템의 인터럽트 핸들러가 리스케줄러(154, 155)를 실행한 경우, 상술한 바와 같이, 공통 인터럽트 핸들러의 처리(247)로 제어가 되돌아가는 일은 없다. 이 경우, 리스케줄러(154, 155)가 새로운 태스크의 우선순위를 우선순위 변환모듈(122, 123)에 통지한다. 이것에 의해서, 우선순위 비교모듈(124)이 오퍼레이팅 시스템의 전환을 행하는지 아닌지를 판정한다.
또, 공통 인터럽트 핸들러(174)의 구성을 도 28과 같이 변경하는 것도 가능하다. 도 29에 나타낸 공통 인터럽트 핸들러(174)는 도 10에 나타낸 공통 인터럽트 핸들러의 구성요소 외에, 인터럽트 우선순위 대응 테이블(380)을 소유한다.
인터럽트 우선순위 대응 테이블(38O)은, 인터럽트 핸들러가 어떠한 정규화 우선순위로 동작해야 하는가를 나타내는 대응표이다. 도 29의 예에서는, 인터럽트 요인 0에 대응하는 인터럽트 핸들러는, 정규화 우선순위(255)로 동작해야 하고, 또한, 인터럽트 요인 31에 대응하는 인터럽트 핸들러는, 정규화 우선순위(224)로 동작해야 한다. 공통 인터럽트 핸들러(174)는 각 오퍼레이팅 시스템의 인터럽트 핸들러를 기동할 때에, 인터럽트 우선순위 대응 테이블(380)에 따라서, 해당 오퍼레이팅 시스템의 정규화 우선순위를 갱신하고, 또한, 인터럽트 핸들러 종료후, 원래의 정규화 우선순위를 복귀시킨다. 또, 이 예에서는 공통 인터럽트 핸들러(174)가 인터럽트 우선순위 대응 테이블(380)을 가지는 것으로 하고 있지만, 인터럽트 우선순위 대응 테이블(380)을 우선순위 변환모듈(122, 123)내에 설치하고, 공통 인터럽트 핸들러(174)로부터 우선순위 변환을 의뢰하는 구성을 채용하는 것도 가능하다.
또, 도 29와 같이, 인터럽트에 대하여도 정규화 우선순위를 할당할 수 있는 것이면, 각 오퍼레이팅 시스템의 모든 동작상태에도 정규화 우선순위를 할당할 수 있다. 예컨대, 오퍼레이팅 시스템은, 일반적으로 이하의 4종류의 동작상태를 가진다.
(1) idle상태
(2) 태스크 실행상태
(3) 오퍼레이팅 시스템 자체의 처리상태(예컨대 초기화 처리)
(4) 인터럽트 처리상태
이들 모두에 정규화 우선순위를 할당하는 것도 가능하다. 이 경우, 일반적으로 생각하여, 인터럽트 처리상태가 가장 우선하여 동작해야 하므로, 가장 높은 정규화 우선순위를 할당한다. 다음에 오퍼레이팅 시스템 자체의 처리상태, 태스크 실행상태, idle상태의 순으로 정규화 우선순위를 할당하게 된다.
도 13은 공통 인터럽트 핸들러(174)로부터 호출되는 사무처리 OS의 인터럽트 핸들러(152)의 처리플로우를 나타낸 것이다. 첫째로, 사용중 레지스터를 인터럽트 스택(214)으로 퇴피하여(처리 250), 인터럽트 처리를 실행한다(처리 251). 여기서, 오퍼레이팅 시스템이 리스케줄링(rescheduling)중인지 아닌지(즉, 리스케줄러(154)의 처리실행중인지 아닌지)를 체크한다(처리 252).
리스케줄링중이란, 다음에 실행해야 할 태스크를 한창 선택하고 있을 때이며, 실제로는 태스크를 실행하지 않고 있는 것을 의미한다. 따라서, 오퍼레이팅 시스템의 처리를 단순화시키면, 이 경우, 다시 리스케줄링을 처음부터 다시 하면 좋다. 즉, 리스케줄링중이라고 판정한 경우, 인터럽트 스택의 퇴피 레지스터를 파기하고(처리 257), 리스케줄러(154)를 처음부터 기동한다(처리 258). 또, 리스케줄링중에 인터럽트가 발생하더라도, 실행해야 할 태스크를 새롭게 선택하여 고칠 필요가 없는 경우도 있다. 본 방식은, 이 상황에서도 리스케줄링을 처음부터 행하게 되어, 효율적이지 않다. 이 때문에, 리스케줄링중에 발생하고, 리스케줄러(154)의 실행에 영향을 주는 처리(예컨대, 태스크 기동·종료등)를 대기행렬 등에 등록해 두는 방법을 사용하는 것도 가능하다. 이 경우, 리스케줄러(154)의 종료전이나 우선순위 통지모듈(12O) 내에서, 해당 대기행렬에 등록해 둔 처리를 종합해서 실행한다. 이 방식을 채용하면, 인터럽트가 발생할 때마다 도중까지 실행하고 있는 리스케줄링을 다시 할 필요가 없다. 그렇지만, 해당 대기행렬에 등록하고 있는 처리를 종합해서 실행한 후, 이것에 의해서 리스케줄링이 다시 필요하게 되는지 아닌지를 다시 체크해야 한다.
또, 본 실시예에서는, 단순화를 위해, 전자의 방식으로 설명을 행한다. 그러나, 후자의 방식을 사용하는 경우,
(a) 스케줄링 중인지 아닌지를 나타내는 플래그
(b) 처리대기행렬
을 준비하면 좋다. 오퍼레이팅 시스템이 제공하는 시스템 호출 등에 있어서, 리스케줄러(154)의 실행에 영향을 주는 처리를, 리스케줄링중이면, 해당 대기행렬에 등록한다. 또, 리스케줄러(154)의 처리 플로우 중에, 해당 대기행렬에 등록된 처리를 일괄해서 실행하는 모듈을 삽입한다.
인터럽트 핸들러(152)가 리스케줄링중이 아니라고 판정한 경우, 해당 오퍼레이팅 시스템은 그 시점에서 어느 것인가의 태스크를 실행하고 있다. 이 때문에, 첫째로, 태스크 전환이 필요한지 아닌지를 판정한다(처리 253). 태스크전환이, 필요하지 않으면(현 실행 태스크가 최고 우선순위이며, 또한, 실행 가능하면), 이대로 인터럽트 핸들러(152)의 처리를 종료한다. 이 때문에, 인터럽트 스택(214) 상에 퇴피해 둔 레지스터 값을 복귀하고(처리 254), 공통 인터럽트 핸들러로 제어를 되돌린다(처리 255). 태스크 전환이 필요하다고 판정한 경우, 인터럽트 스택(214) 상에 퇴피한 레지스터의 값을 태스크 관리 테이블에 복사하고(처리 256), 인터럽트 스택 상의 퇴피 레지스터를 파기한다(처리 257). 이 후에, 리스케줄러(154)를 기동한다(처리 258). 또, 프로세서(100)에, 메모리(101) 위의 데이터를 참조하여, 동시에, 인터럽트 스택 포인터(216)의 값을 증감할 수 있는 기능이 갖춰져 있으면, 처리 256과 처리 257을 종합해서 실행하는 것이 가능하다.
다음에, 로크 취득모듈(219), 로크 해방모듈(220)의 처리 플로우를 설명한다. 여기서는, 우선순위 상승방식을 사용하는 예를 설명하고, 우선순위 계승방식을 사용하는 실시예에 관해서는 후술한다. 또, 여기서는, 로크 취득·해방을 요구한 태스크, 및 그것을 관리하는 오퍼레이팅 시스템을 자신의 태스크, 자신의 오퍼레이팅 시스템이라고 부르고, 또 한 편의 오퍼레이팅 시스템을 다른 오퍼레이팅 시스템이라고 부르고 있다.
도 14는 우선순위 상승방식을 사용하는 로크 취득모듈(219)의 처리플로우이다. 로크 취득모듈(219)은, 첫째로, 다른 오퍼레이팅 시스템의 태스크가 로크 취득중인지 아닌지를 체크하고(처리 260), 취득중이 아니면, 자신의 오퍼레이팅 시스템이 로크의 소유자이도록 설정한다(처리261). 다른 오퍼레이팅 시스템의 태스크가 로크 취득중이면, 로크가 해방될 때까지 태스크를 대기상태로 이행시킨다(처리 263). 이때, 다른 오퍼레이팅 시스템을 우선하여 실행시키고, 해당 로크를 신속하게 해방시키도록 해야 한다. 이 때문에, 우선순위 비교모듈(124) 내에 기억되어 있는 다른 오퍼레이팅 시스템의 정규화 우선순위를 자신의 오퍼레이팅 시스템보다 높게 되도록 변경한다(처리 262). 여기서 처리 263에 있어서 태스크를 대기상태로 이행시키면, 자신의 오퍼레이팅 시스템에서 리스케줄러가 기동된다. 이에 따라, 리스케줄러로부터, 우선순위 통지모듈, 우선순위 변환모듈, 우선순위 비교모듈이 순차 호출되고, 정규화 우선순위를 높게 변경한 다른 오퍼레이팅 시스템으로 전환이 행해지게 된다.
도 15는 우선순위 상승방식을 사용하는 경우의 로크 해방모듈(220)의 처리플로우이다. 첫째로, 자기가 소유하는 로크를 석방한다(처리 270). 다음에, 다른 오퍼레이팅 시스템이 로크 취득대기인지 아닌지를 체크한다(처리 271). 로크 취득대기가 아니면, 정규화 우선순위의 상승은 행해지지 않는다. 이 때문에, 이대로 로크 해방모듈(220)의 처리를 종료한다. 그러나, 다른 오퍼레이팅 시스템이 로크 취득대기이면, 우선순위 역전현상을 해결하기 위해서, 정규화 우선순위의 상승이 행해질 예정이다. 따라서, 자기의 오퍼레이팅 시스템의 정규화 우선순위를 원래의 값으로 되돌리고(처리 272), 다음에, 다른 오퍼레이팅 시스템에서 로크 취득대기로 되어 있는 태스크를 실행 가능상태로 이행시킨다(처리 273). 로크 취득대기 태스크를 실행 가능하게 함으로써 태스크 전환이 발생하면, 다른 오퍼레이팅 시스템의 리스케줄러가 기동되고, 전술의 로크 취득모듈의 경우와 같이 최종적으로, 우선순위 비교모듈(124)이 실행된다. 이에 따라, 원래의 정규화 우선순위를 사용하여 오퍼레이팅 시스템의 중요성이 비교되고, 보다 높은 정규화 우선순위를 가진 오퍼레이팅 시스템이 선택된다.
다음에, 우선순위 계승방식을 사용하는 예를 설명한다. 이 경우, 도 16에 나타낸 바와 같이, 각 오퍼레이팅 시스템은, 정규화 우선순위에 따라서 태스크의 우선순위를 변경하는 우선순위 설정모듈(280, 281)을 장비해야 한다. 또한, 우선순위 변환모듈(122, 123)은, 우선순위를 정규화 우선순위로 변환하는 기능 외에, 정규화 우선순위를 우선순위로 변환하는 기능을 탑재해야 한다. 이 때문에, 우선순위 변환모듈(122, 123)은 정규화 우선순위를 인덱스(index)로 하고, 각 오퍼레이팅 시스템의 우선순위를 내용으로 하는 우선순위 역변환 테이블(282, 283)을 갖는다.
오퍼레이팅 시스템은, 일반적으로, 시스템 호출로서, 태스크의 우선순위를 변경하는 기능을 가지고 있다. 우선순위 설정모듈(280, 281)은 주어진 정규화 우선순위를 각 오퍼레이팅 시스템에 대응하는 우선순위로 변환하고, 태스크 우선순위 변경 시스템 호출 등을 사용하여 태스크의 우선순위를 변경한다. 우선순위 역변환 테이블(282, 283)은 우선순위 설정모듈(280, 281)의 기능을 서포트하는 역할을 한다. 본 실시예에서는, 정규화 우선순위가 O∼255이기 때문에, 우선순위 역변환 테이블(282, 283)은, 256개의 엔트리를 가진 배열이다. 또한, 사무처리 OS(110)의 우선순위의 범위가 O∼31이기 때문에, 우선순위 역변환 테이블(282)의 각 배열요소는, O∼31의 범위의 어느 것인가의 정수를 갖고, 또한 이하의 부등식을 만족한다(배열의 명칭을 revBusiness로 한다).
i 〉 jrevBusiness [i]revBusiness [j]
(단, 0i, j255)
실시간 OS(111)는 우선순위 O∼255를 갖고, 또한 우선순위의 수치가 작을수록 우선순위가 높다고 하는 특징을 갖기 때문에, 우선순위 역변환 테이블(283)의 각 배열요소는, 0∼255까지의 어느 것인가의 정수를 갖고, 또한 이하의 부등식을 만족한다(배열의 명칭을 revRealtime로 한다).
i 〉 j ⇒ revRealtime [i]revRealtime [j]
(단, 0i, j255)
그런데, 본 실시예에서는, 정규화 우선순위의 수치가 O∼255, 실시간 OS의 우선순위의 수치가 0∼255이라고 하고 있기 때문에, 정규화 우선순위와 실시간 OS의 우선순위와의 대응 설치를 1:1로 행할 수 있다. 따라서, 우선순위 변환 테이블(171)로부터 일의(一意)로 우선순위 역변환 테이블(283)을 도출할 수 있다. 그렇지만, 사무처리 OS의 우선순위의 수치는 O∼31이기 때문에, 우선순위 역변환 테이블(282)을 일의로 정할 수 없다. 이 경우, 예컨대, 정규화 우선순위「1」에 대응하는 사무처리 OS의 우선순위를, 우선순위 변환 테이블(17O)로부터 도출할 수 없다. 이 때문에, 일의로 정할 수 없는 정규화 우선순위에 대하여는, 상기 부등식을 만족하도록, 사무처리 OS의 우선순위를 적절하게 정하고 있다.
우선순위 변환모듈(122) 중, 우선순위 역변환 기능의 처리플로우에 관해서 도 17에 나타내었다. 여기서는, 지정 정규화 우선순위에 대응하는 사무처리 OS의 우선순위를 우선순위 역변환 테이블(282)로부터 추출하고(처리290), 해당 우선순위를 우선순위 설정모듈(280)에 통지한다(처리291). 우선순위 변환모듈(123)도 같은 우선순위 역변환기능을 갖는다.
이것에 대한 우선순위 설정모듈(280)의 처리플로우를 도 18에 나타낸다. 우선순위 설정모듈(280)은, 첫째로, 우선순위 변환모듈(122)에 의뢰하여, 정규화 우선순위로부터 사무처리 OS의 우선순위로의 변환을 행하게 한다(처리 292). 다음에, 사무처리 OS의 우선순위 변경 시스템 호출 등을 사용하여 태스크의 우선순위를 변경시킨다(처리 293). 실시간 OS(111)에 있어서의 우선순위 설정모듈(281)의 처리도 마찬가지이다.
다음에, 이것들의 우선순위 역변환기능, 우선순위 설정모듈을 사용한 우선순위 계승방식의 실현방법에 관해서 서술한다.
도 19는 우선순위 계승방식을 사용하는 로크 취득모듈(219)의 처리플로우이다. 로크 취득모듈(219)은, 첫째로, 다른 태스크가 로크 취득중인지 아닌지를 체크하고(처리 300), 취득중이 아니면, 자기의 태스크가 로크의 소유자이도록 설정한다(처리 301). 다른 태스크가 로크 취득중이면, 로크가 해방될 때까지 태스크를 대기상태로 이행시킬 필요가 있다(처리 304).
이때, 로크 취득중 태스크를 우선하여 실행시키고, 해당 로크를 신속하게 해방시키도록 해야 한다. 로크 취득중 태스크의 정규화 우선순위와 자기의 태스크의 정규화 우선순위를 비교하고(처리 302), 로크 취득중 태스크의 정규화 우선순위가 낮으면, 해당 태스크에 자기의 태스크의 우선순위를 계승시킨다(처리 303). 우선순위계승은, 로크 취득중 태스크를 실행하는 오퍼레이팅 시스템의 우선순위 설정모듈에 대하여, 자기의 태스크의 정규화 우선순위를 지정하여 우선순위설정을 의뢰함으로써 행할 수 있다. 로크 취득중 태스크의 정규화 우선순위가 이미 자기의 태스크의 정규화 우선순위보다 높으면, 우선순위 계승을 행할 필요가 없어, 즉시 태스크를 대기상태로 이행시킬 수 있다.
도 20은 우선순위 계승방식을 사용하는 로크 해방모듈(220)의 처리플로우이다. 첫째로, 자기가 소유하는 로크를 석방한다(처리 31O). 다음에, 다른 태스크가 로크 취득대기인지 아닌지를 체크한다(처리 311). 로크 취득대기가 아니면, 정규화 우선순위 계승이 행해지지 않게 되고, 이대로 로크 해방모듈(220)의 처리를 종료한다. 그러나, 다른 태스크가 로크 취득대기이면, 정규화 우선순위 계승이 행해질 예정이다. 따라서, 우선순위 설정모듈에 의뢰하여 자기의 태스크의 정규화 우선순위를 원래의 값으로 되돌리고(처리 312), 다음에, 로크 취득대기로 되어 있는 태스크를 실행 가능상태로 이행시킨다(처리 313).
본 실시예에서는 설명을 생략하였지만, 로크 취득모듈(219), 로크 해방모듈(220) 등을 실행하고 있는 도중에 인터럽트가 발생하고, 태스크 전환 등이 발생하면, 로크 소유자를 나타내는 데이터 등에 부정합이 생길 가능성이 있다. 따라서, 통상, 이것들의 처리 실행중에는, 인터럽트 마스크 기능에 의해서 인터럽트 발생을 억지한다.
도 16∼도 20에 나타낸 프로그램 모듈, 처리플로우에 의해, 오퍼레이팅 시스템 사이에서의 배타제어에 있어서, 우선순위 계승방식을 사용하는 것이 가능해진다. 또, 실제로는, 도 19, 도 20에 나타낸 처리플로우를 사용하는 것에 의해, 하나의 오퍼레이팅 시스템 내에서 정규화 우선순위의 계승을 행하는 것도 가능하다.
도 21에, 인터럽트 마스크 레벨 계산모듈(177)의 내부구조를 나타내었다. 인터럽트 마스크 레벨 계산모듈(177)은, 정규화 우선순위를 인터럽트 마스크 레벨로 변환하고, 일정 이상의 정규화 우선순위이면, 특정한 인터럽트를 마스크하는 기능이다. 이것은, 어떤 일정 이상의 정규화 우선순위를 가진 태스크는, 인터럽트 처리보다도 우선하여 실행되야 한다라는 생각에 근거하는 기능이다. 따라서, 시스템 호출 등으로 인터럽트를 마스크하는 기능이 갖춰져 있으면, 본 기능이 존재하지 않더라도 충분히 시스템은 성립한다. 단지, 인터럽트 마스크 레벨 계산모듈(177)의 이점으로서, 정규화 우선순위가 일정값 이상으로 되면, 자동적으로 인터럽트 마스크를 실행한다.
인터럽트 마스크를 실행하기 위해서, 인터럽트 마스크 레벨 계산모듈(177)은, 인터럽트 마스크 변환 테이블(320)을 소유한다. 인터럽트 마스크 변환 테이블(320)은, 정규화 우선순위로부터 인터럽트 마스크값을 입수하기 위한 변환 테이블이다.
본 실시예에서는, 도 4에 도시한 바와 같이, 32종류의 인터럽트 요인을 개별적으로 마스크할 수 있는 계산기 구조를 대상으로 하고 있기 때문에, 인터럽트 마스크 변환 테이블(32O)의 각 엔트리는 32비트 길이 데이터를 갖는다. 그렇지만, 도 3에 도시한 바와 같이, 4비트의 인터럽트 마스크 레벨을 사용하면, 인터럽트 마스크 변환 테이블(32O)의 각 엔트리를 4비트 길이로 축소시킬 수 있다. 여기서, 도 21에 나타낸 실시예에서는, 예컨대, 정규화 우선순위「0」에 대응하는 인터럽트 마스크값이 0x00000000이며, 정규화 우선순위「255」에 대응하는 인터럽트 마스크값은 0xffffffff이다. 이것은, 정규화 우선순위가「O」이면 모든 인터럽트를 허가하고, 최고의 정규화 우선순위로 시스템이 동작하고 있으면, 모든 인터럽트를 마스크하는 것을 의미한다. 우선순위 비교모듈(124)이 인터럽트 마스크 레벨 계산모듈(177)에 대하여, 현재 실행중 오퍼레이팅 시스템의 정규화 우선순위를 통지함으로써, 필요한 인터럽트 마스크를 자동적으로 행할 수 있다.
도 22에 인터럽트 마스크 레벨 계산모듈(177)의 처리플로우를 나타낸다. 여기서는, 첫째로, 정규화 우선순위에 대응하는 인터럽트 마스크값을 인터럽트 마스크 변환 테이블(320)로부터 추출한다(처리 330). 다음에, 입수한 인터럽트 마스크값을 인터럽트 마스크 레지스터(143)등에 설정하여, 인터럽트 마스크를 실시한다(처리 331).
이상으로 본 발명의 제1 실시예에 관해서 설명하였다. 본 실시예를 사용함으로써, 각 오퍼레이팅 시스템이 실행하고 있는 태스크의 우선순위에 따라서, 오퍼레이팅 시스템의 전환을 행할 수 있다. 본 실시예에서는, 각 오퍼레이팅 시스템 내에 우선순위 통지모듈을 조립하고, 리스케줄링할 때마다 우선순위의 변경을 통지하도록 개조해야 한다. 그렇지만, 시판되어 있는 오퍼레이팅 시스템을 사용하는 경우 등, 이러한 개조를 시행할 수 없는 것도 많다. 이하, 이것에 대처하는 본 발명의 제 2 실시예에 관해서 설명한다.
도 23은 본 발명의 제2 실시예를 나타내는 구성도이다. 사무처리 OS(110), 실시간 OS(111)는, 각각, 현재 실행중 태스크의 우선순위(실행 우선순위(340, 341))를 유지하는 것으로 한다. 각 오퍼레이팅 시스템은, 도 5에 나타내는 실행가능 대기행렬(150, 151)의 선두에 존재하는 태스크 관리 테이블(162, 163) 내에 격납되어 있는 우선순위의 수치가 실행 우선순위(340, 341)로 된다. 또한, 실행가능 대기행렬이 우선순위마다 복수개 존재하는 경우에는, 일반적으로, 현 시점에서 최고 우선순위의 실행가능 대기행렬이 어디에 존재하는가를 나타내는 포인터나, 최고 우선순위의 수치 그 자체를 나타내는 변수(우선순위 유지변수)를 준비하는 것이 많다. 전자의 경우에는, 해당 포인터로부터 실행가능 대기행렬을 찾아, 태스크 관리 테이블을 참조함으로써, 후자의 경우에는, 해당 우선순위 유지변수 자체를 판독함으로써, 실행 우선순위(34O, 341)를 입수할 수 있다.
오퍼레이팅 시스템 전환 프로그램(118) 내에는, 새롭게, 우선순위 감시모듈(344)을 설치한다. 이외의 모듈인, 우선순위 변환모듈(122, 123), 우선순위 비교모듈(124), 공통 인터럽트 핸들러(174), OS간 통신 기능모듈(175), OS 콘텍스트 전환모듈(176), 인터럽트 마스크 레벨 계산모듈(177)은, 제 1 실시예에서 설명한 내용과 같은 구성, 처리 플로우를 갖는다. 각 오퍼레이팅 시스템 내에는, 우선순위 통지모듈(120, 121)은 존재하지 않는다.
우선순위 감시모듈(344)은, 사무처리 OS 실행 우선순위 기억값(342)과 실시간 OS 실행 우선순위 기억값(343)을 소유한다. 우선순위 감시모듈(344)은 정기적으로 기동되어, 각 오퍼레이팅 시스템의 실행 우선순위(34O, 341)를 감시한다. 여기서, 기억하고 있는 실행 우선순위(342 또는 343)와, 현재의 실행 우선순위(340 또는 341)가 다르면, 우선순위가 변화되었다고 인식하여, 우선순위 변환모듈(122 또는 123)에 새로운 실행 우선순위를 통지한다.
우선순위 감시모듈(344)의 처리플로우를 도 24에 나타낸다. 첫째로, 사무처리 OS의 실행 우선순위(340)를 판독하여, 이것을 사무처리 OS 실행 우선순위 기억값(342)과 비교한다(처리 350). 이에 따라, 사무처리 OS의 우선순위가 변화되었는지 아닌지를 인식할 수 있다. 우선순위가 변화되어 있지 않으면 아무것도 실행하지 않고, 처리 353으로 이행한다. 우선순위가 변화되어 있으면, 사무처리 OS의 실행 우선순위(340)를 사무처리 OS 실행 우선순위 기억값(342)에 등록하고(처리 351),다음에, 해당 우선순위를 사무처리 OS의 우선순위 변환모듈(122)에 통지한다(처리 352). 실시간 OS(111)의 실행 우선순위 변화에 대하여도 같은 처리를 행한다. 첫째로, 실시간 OS의 실행 우선순위(341)와 실시간 OS 실행 우선순위 기억값(343)과의 비교를 행하고(처리 353), 우선순위의 변화가 없으면 처리를 종료한다. 우선순위가 변화되어 있으면, 실시간 OS의 실행 우선순위(341)를 실시간 OS 실행 우선순위 기억값(343)에 등록하고(처리 354),이것을 실시간 OS의 우선순위 변환모듈(123)에 통지한다(처리 355).
또, 우선순위 변환모듈에 우선순위를 통지한 결과, 오퍼레이팅 시스템의 전환이 행해지면, 우선순위 감시모듈(344)로 제어가 되돌아가지 않는다는 것에 주의해야 한다. 이 때문에, 도 24의 감시방법은, 항상 사무처리 OS(11O)의 우선순위 변화를 우선하여 감시하는 것이라고 말 할 수 있다. 양 오퍼레이팅 시스템의 감시를 대등한 것으로 하기 위해서는, 우선순위 감시모듈(344)의 기동회수를 계수해 두고,
(1) 기동회수가 홀수이면 사무처리 OS(110)의 우선순위 변화를 감시하고,
(2) 기동회수가 짝수이면 실시간 OS(111)의 우선순위 변화를 감시하는 처리플로우 등으로 변경해야 한다.
여기서, 우선순위 감시모듈(344)은, 「정기적으로」기동되어, 우선순위의 변화를 감시한다는 것에 주의해야 한다. 정기적인 처리를 실현하기 위해서는, 타이머 인터럽트에 의해서 우선순위 감시모듈(344)을 기동하면 된다.
여기서는, 타이머 인터럽트, 외부 인터럽트를 포함하는 모든 인터럽트가 공통 인터럽트 핸들러(174)로 일괄 처리되는 것에 착안하여, 공통 인터럽트 핸들러(174) 내에 우선순위 감시모듈(344)을 매립하는 방법에 관해서 설명한다. 도 25는 우선순위 감시모듈(344)을 매립한 공통 인터럽트 핸들러(174)의 처리플로우이다.
도면 중, 처리 24O∼248은 모두 도 12와 같다. 우선순위 감시모듈(344)의 기동(처리 360)은 오퍼레이팅 시스템 전환을 행하는 가능성이 있다. 이 때문에, 인터럽트 핸들러의 실행(처리 245, 246)후에 매립해야 한다. 인터럽트 핸들러(152, 153)가 공통 인터럽트 핸들러(174)로 제어를 되돌리면, 자동적으로 우선순위 변화가 감시되고, 필요에 따라서 오퍼레이팅 시스템의 전환이 행해진다. 우선순위 감시모듈(344)이 오퍼레이팅 시스템의 전환을 행할 필요가 없다라고 판단한 경우, 그대로 공통 인터럽트 핸들러(174)의 처리를 종료한다.
또, 본 발명의 제 2 실시예에서는, 리스케줄링 직후의 우선순위 변화를 우선순위 변환모듈에 통지하는 수단이 존재하지 않는다. 즉, 일정 간격마다 우선순위의 변화를 체크하는 것이고, 우선순위의 변화에 즉시 반응하여 오퍼레이팅 시스템을 전환하는 것은 안 된다. 이 때문에, 본 발명의 제 2 실시예는, 오퍼레이팅 시스템 내부의 개조를 따르지 않는 계산기를 실현할 수 있지만, 제 1 실시예에 비하여, 전환 효율이 뒤떨어진다고 하는 특징이 있다.
본 발명의 제 2 실시예는, 양 오퍼레이팅 시스템의 내부를 개조하지 않는다고 하는 조건을 만족하는 것이지만, 예컨대, 실시간 OS(111)는 개조할 수 있지만, 사무처리 OS(110)는 개조할 수 없다고 한 조건을 발생하는 것도 있다. 이 경우, 본 발명의 제3 실시예로서, 실시간 OS(111) 내부에 우선순위 통지모듈(121)을 탑재하고, 우선순위 감시모듈(344)은 사무처리 OS(110)의 우선순위 변화만을 감시한다고 한 계산기를 실현하는 것도 가능하다(도 26).
또한, 리스케줄러 내부에 우선순위 통지모듈을 조립하는 것이 아니라, 각 오퍼레이팅 시스템의 타이머 인터럽트 처리모듈 내부 등, 정기적으로 기동되는 부분에 우선순위 통지모듈을 조립하고, 우선순위 감시모듈(344)의 대용으로 하는 것도 가능하다.
이상 설명한 본 발명을 도 27에 나타내는 차재 네비게이션 시스템에 적용한 경우, 처리시간이 긴 경로탐색 태스크가 동작하고 있는 경우에서도 사용자로부터의 입력을 접수할 수 있다. 요컨대, 이 경우는 인터페이스 태스크에 대하여, 경로탐색 태스크보다도 높은 정규화 우선순위를 준다. 이때, 사용자가 버튼을 눌러 인터페이스 태스크가 동작하면, 보다 정규화 우선순위가 높은 태스크를 동작시키는 사무처리 OS에 전환이 행해지고, 결과로서, 처리가 긴 경로탐색 태스크가 동작하고 있는 경우에도 인터페이스 태스크가 실행되게 된다.
또, 복수의 오퍼레이팅 시스템을 실행하는 가상 계산기에 있어서도, 본 발명을 적용함으로써 다른 우선순위 체계를 가지고 있는 오퍼레이팅 시스템을, 실행해야 할 태스크의 우선순위에 따라서 실행시킬 수 있다.
이상으로, 본 발명에 의하면 사무처리용 OS의 사용자 인터페이스와 실시간 OS의 신뢰성을 함께 갖는 계산기를 구축할 수 있다.
상기 제 1 내지 제 3 실시예는, 모두, 오퍼레이팅 시스템 전환 프로그램(118)의 내부에서 우선순위의 변환을 행하는 구성을 가지고 있다. 그렇지만, 우선순위 변환모듈(122, 123)은, 각각, 사무처리 OS(110), 실시간 OS(111)에 개별적으로 대응하고 있기 때문에, 이들을, 각 오퍼레이팅 시스템 내부에 탑재해도 좋다. 이러한 변경을 가한 제 4 실시예를 도 29에 나타낸다.
본 실시예에서는, 첫째로, 우선순위 변환모듈(122, 123)이 각 오퍼레이팅 시스템에서의 우선순위를 정규화 우선순위로 변환한다. 이것을 받아, 우선순위 통지모듈(120,121)이, 우선순위 비교모듈(124)에 대하여 각 오퍼레이팅 시스템의 정규화 우선순위를 통지한다.
이 실시예에서는, 사무처리 OS(11O), 실시간 OS(111)와 오퍼레이팅 시스템 전환 프로그램(108)과의 인터페이스가 모두 정규화 우선순위에 의해서 행해진다. 상기 제 1 내지 제 3 실시예에서는, 실행가능 태스크가 존재하는 경우에는, 태스크의 우선순위를 통지하고, 실행가능 태스크가 존재하지 않은 경우에는, id1e상태인 것을 통지하고 있었다. 이것들의 경우, idle상태나, 오퍼레이팅 시스템 자체가 어느 것인가의 처리를 실행해야만 하는 상태를, 자유롭게 정규화 우선순위에 맵핑할 수 없다. 본 실시예(제4실시예)에서는, 각 오퍼레이팅 시스템 내에서 우선순위를 정규화 우선순위로 변환하기 위해서, 태스크 실행중 이외의 상태도 자유롭게 정규화 우선순위에 맵핑하는 것이 가능해진다.
본 발명에 의하면, 복수개의 오퍼레이팅 시스템을 단일 프로세서로 동작시키는 계산기에 있어서, 각 오퍼레이팅 시스템이 실행하는 태스크의 우선순위에 따라서, 오퍼레이팅 시스템의 전환을 행할 수 있고, 보다 중요한 태스크를 우선하여 실행시킬 수 있다. 또한, 본 발명에서는, 우선순위 변환모듈에 의해서 정규화 우선순위로 변환하고, 이것에 의해서 오퍼레이팅 시스템 사이의 우선순위 비교를 행하기 때문에, 다른 우선순위 체계를 가지는 오퍼레이팅 시스템끼리를 실행시키는 계산기만으로 실시간성·효율성을 손상시키는 일은 없다.

Claims (10)

  1. 복수의 오퍼레이팅 시스템과, 각각의 상기 오퍼레이팅 시스템의 프로그램 상에서 실행되는 복수의 프로세스 또는 스레드를 기억한 메모리와,
    각각의 상기 프로세스 또는 스레드에 할당된 우선순위에 근거하여, 오퍼레이팅 시스템을 실행하는 처리장치를 가진 계산기에 있어서,
    상기 처리장치는, 각각의 상기 오퍼레이팅 시스템으로 실행해야 할 프로세스 또는 스레드의 우선순위를 판독하고, 각각 판독된 우선순위를 복수의 상기 오퍼레이팅 시스템 사이에서 공통의 우선순위로 변환하며, 상기 변환결과에 근거하여 우선하여 실행해야 할 오퍼레이팅 시스템을 결정하는 동시에, 상기 결정된 오퍼레이팅 시스템을 실행하는 것을 특징으로 하는 계산기.
  2. 제 1 항에 있어서,
    상기 메모리는 복수의 상기 오퍼레이팅 시스템에서 실행해야 할 프로세스 또는 스레드의 우선순위를 상기 공통의 우선순위에 맵핑하기 위한 우선순위 변환 테이블을 갖고, 상기 프로세서는 상기 변환 테이블에 근거하여 우선하여 실행해야 할 오퍼레이팅 시스템을 결정하는 것을 특징으로 하는 계산기.
  3. 제 1 항 또는 제 2 항에 있어서,
    상기 프로세서는, 복수의 오퍼레이팅 시스템 사이에서 공통의 우선순위로부터, 각각의 상기 오퍼레이팅 시스템에 있어서의 우선순위를 결정하고, 각각의 오퍼레이팅 시스템에서 실행되는 복수의 상기 프로세스 또는 스레드의 우선순위를 변경하는 것을 특징으로 하는 계산기.
  4. 제 3 항에 있어서,
    상기 메모리는, 상기 공통의 우선순위를 각각의 상기 오퍼레이팅 시스템에 있어서의 우선순위에 맵핑하기 위한 우선순위 역변환 테이블을 갖고, 상기 프로세서는, 상기 우선순위 역변환 테이블에 근거하여 복수의 상기 프로세스 또는 스레드의 우선순위를 변경하는 것을 특징으로 하는 계산기.
  5. 제 1 항 내지 제 4 항 중 어느 한 항에 있어서,
    상기 프로세서는 프로세스 또는 스레드가 지정된 처리를 실행하는 경우에, 해당 프로세스 또는 스레드를 실행하는 오퍼레이팅 시스템의 우선순위를 상승시키고, 상기 프로세스 또는 스레드가 해당 지정된 처리를 종료한 경우에, 상기 오퍼레이팅 시스템의 우선순위를 하강시키는 것을 특징으로 하는 계산기.
  6. 복수의 프로세스 또는 스레드와,
    복수의 상기 프로세스 또는 스레드를 실행하는 동시에, 실행하고 있는 프로세스 또는 스레드의 우선순위를 통지하는 복수의 오퍼레이팅 시스템과,
    각각의 상기 오퍼레이팅 시스템으로부터 통지된 우선순위를 오퍼레이팅 시스템 사이에서 공통의 우선순위로 변환하는 우선순위 변환처리와,
    상기 우선순위 변환처리에 의해서 얻어진 공통의 우선순위를 비교하여, 보다 높은 공통의 우선순위를 가진 오퍼레이팅 시스템을 우선적으로 실행시키는 우선순위 비교처리를 기억한 것을 특징으로 하는 정보기억매체.
  7. 복수의 오퍼레이팅 시스템을 선택적으로 실행하는 오퍼레이팅 시스템 실행방법에 있어서,
    우선순위 변환처리에 의해서, 각각의 상기 오퍼레이팅 시스템에서 실행되는 프로세스 또는 스레드의 우선순위를 오퍼레이팅 시스템 사이에서 공통의 우선순위로 변환하고,
    우선순위 비교처리에 의해서, 상기 우선순위 변환처리에 의해서 얻어진 공통의 우선순위를 비교하여, 보다 높은 공통의 우선순위를 가진 오퍼레이팅 시스템을 우선적으로 실행시키는 것을 특징으로 하는 오퍼레이팅 시스템 실행방법.
  8. 제 7 항에 있어서,
    상기 우선순위 변환처리는 각각의 오퍼레이팅 시스템의 우선순위를 상기 공통의 우선순위로 변환하는 것이고, 다른 오퍼레이팅 시스템의 우선순위는 서로 다른 공통의 우선순위로 변환하는 것을 특징으로 하는 오퍼레이팅 시스템 실행방법.
  9. 제 7 항 또는 제 8 항에 있어서,
    상기 우선순위 변환처리는, 각각의 상기 오퍼레이팅 시스템이 실행하고 있는 프로세스 또는 스레드의 우선순위를 상기 공통의 우선순위로 변환하는 것 이외에, 적어도, 인터럽트 처리중의 상태, 오퍼레이팅 시스템 자체의 기능 실행중의 상태, 실행해야 할 처리가 존재하지 않은 상태라고 하는 3종류의 상태를 공통의 우선순위로 변환하는 것을 특징으로 하는 오퍼레이팅 시스템 실행방법.
  10. 복수의 프로세스 또는 스레드를 해당 복수의 프로세스 또는 스레드에 할당된 우선순위에 따라서 실행하는 복수개의 오퍼레이팅 시스템과, 해당 복수개의 오퍼레이팅 시스템을 전환하는 수단을 가진 계산기 시스템에 있어서, 해당 복수개의 오퍼레이팅 시스템은, 각각이 실행하고 있는 프로세스 또는 스레드의 우선순위를 계산기 시스템 내에서 공통의 우선순위로 변환하는 우선순위 변환수단과, 해당 우선순위 변환수단으로부터 얻어진 공통의 우선순위를 해당 오퍼레이팅 시스템으로 전환하는 수단에 통지하는 우선순위 통지수단을 갖고, 해당 오퍼레이팅 시스템을 전환하는 수단은, 각각의 오퍼레이팅 시스템으로부터 통지된 공통의 우선순위를 비교하여, 보다 높은 공통의 우선순위를 가진 오퍼레이팅 시스템을 우선적으로 실행시키는 우선순위 비교수단을 가진 것을 특징으로 하는 계산기 시스템.
KR1020000007733A 1999-02-19 2000-02-18 복수의 오퍼레이팅 시스템을 실행하는 계산기 KR100759280B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP04103299A JP4072271B2 (ja) 1999-02-19 1999-02-19 複数のオペレーティングシステムを実行する計算機
JP11-041032 1999-02-19

Publications (2)

Publication Number Publication Date
KR20000076691A true KR20000076691A (ko) 2000-12-26
KR100759280B1 KR100759280B1 (ko) 2007-09-17

Family

ID=12597071

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020000007733A KR100759280B1 (ko) 1999-02-19 2000-02-18 복수의 오퍼레이팅 시스템을 실행하는 계산기

Country Status (8)

Country Link
US (1) US7810096B2 (ko)
EP (1) EP1031924B1 (ko)
JP (1) JP4072271B2 (ko)
KR (1) KR100759280B1 (ko)
CN (1) CN1264078A (ko)
AT (1) ATE444523T1 (ko)
DE (1) DE60043032D1 (ko)
TW (1) TW490638B (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100731983B1 (ko) * 2005-12-29 2007-06-25 전자부품연구원 저전력 무선 디바이스 프로세서용 하드와이어드 스케줄러및 스케줄링 방법

Families Citing this family (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001256067A (ja) * 2000-03-08 2001-09-21 Mitsubishi Electric Corp プロセッサ省電力制御方法、記憶媒体、およびプロセッサ省電力制御装置
GB2369464B (en) * 2000-11-27 2005-01-05 Advanced Risc Mach Ltd A data processing apparatus and method for saving return state
CN100356349C (zh) * 2001-04-27 2007-12-19 邵通 一种实现计算设备状态转换的装置及方法
CN100356350C (zh) * 2001-04-27 2007-12-19 邵通 实现计算设备状态转换装置安全操作的装置和方法
JP2003067201A (ja) * 2001-08-30 2003-03-07 Hitachi Ltd コントローラとオペレーティングシステム
US7069442B2 (en) 2002-03-29 2006-06-27 Intel Corporation System and method for execution of a secured environment initialization instruction
US20040023646A1 (en) * 2002-07-31 2004-02-05 Satoshi Inami Information processing terminal and information processing method
US7496494B2 (en) 2002-09-17 2009-02-24 International Business Machines Corporation Method and system for multiprocessor emulation on a multiprocessor host system
GB2396712B (en) * 2002-11-18 2005-12-07 Advanced Risc Mach Ltd Handling multiple interrupts in a data processing system utilising multiple operating systems
GB0226874D0 (en) 2002-11-18 2002-12-24 Advanced Risc Mach Ltd Switching between secure and non-secure processing modes
GB2395313B (en) * 2002-11-18 2005-11-23 Advanced Risc Mach Ltd Task following between multiple operating systems
JP3953449B2 (ja) * 2003-08-26 2007-08-08 富士通株式会社 タスク管理プログラムおよびタスク制御装置
JP4112511B2 (ja) 2004-02-17 2008-07-02 富士通株式会社 タスク管理プログラムおよびタスク管理装置
US8707317B2 (en) 2004-04-30 2014-04-22 Microsoft Corporation Reserving a fixed amount of hardware resources of a multimedia console for system application and controlling the unreserved resources by the multimedia application
US7716669B2 (en) * 2004-04-30 2010-05-11 Microsoft Corporation Concurrent system applications in a multimedia console
US8271976B2 (en) 2004-06-30 2012-09-18 Microsoft Corporation Systems and methods for initializing multiple virtual processors within a single virtual machine
US8561076B1 (en) * 2004-06-30 2013-10-15 Emc Corporation Prioritization and queuing of media requests
US20060010446A1 (en) * 2004-07-06 2006-01-12 Desai Rajiv S Method and system for concurrent execution of multiple kernels
WO2006018307A2 (en) * 2004-08-18 2006-02-23 Jaluna Sa Operating systems
US7840962B2 (en) * 2004-09-30 2010-11-23 Intel Corporation System and method for controlling switching between VMM and VM using enabling value of VMM timer indicator and VMM timer value having a specified time
EP1820100B1 (en) * 2004-11-30 2008-08-27 Koninklijke Philips Electronics N.V. Efficient switching between prioritized tasks
US8274518B2 (en) 2004-12-30 2012-09-25 Microsoft Corporation Systems and methods for virtualizing graphics subsystems
WO2006069538A1 (fr) * 2004-12-31 2006-07-06 Juhang Zhong Systeme de traitement de donnees avec pluralite de sous-systemes et procede correspondant
US7437546B2 (en) * 2005-08-03 2008-10-14 Intel Corporation Multiple, cooperating operating systems (OS) platform system and method
US7719132B2 (en) 2005-09-28 2010-05-18 L3 Communications Corporation Ruggedized mobile computing device
US20070104340A1 (en) * 2005-09-28 2007-05-10 Knowles Electronics, Llc System and Method for Manufacturing a Transducer Module
US8104033B2 (en) * 2005-09-30 2012-01-24 Computer Associates Think, Inc. Managing virtual machines based on business priorty
JP5109250B2 (ja) * 2005-11-08 2012-12-26 横河電機株式会社 分散システム
CN101359312B (zh) * 2006-01-17 2010-06-09 株式会社Ntt都科摩 输入输出控制***
JP4342576B2 (ja) * 2006-07-25 2009-10-14 株式会社エヌ・ティ・ティ・ドコモ 複数オペレーティングシステム切替制御装置及びコンピュータシステム
EP1892625B1 (en) * 2006-08-09 2018-07-11 Red Bend Software Finer grained operating system scheduling
US7689820B2 (en) * 2006-09-27 2010-03-30 L3 Communications Corporation Rapid-boot computing device with dual operating systems
US8819483B2 (en) 2006-09-27 2014-08-26 L-3 Communications Corporation Computing device with redundant, dissimilar operating systems
JP4785142B2 (ja) * 2007-01-31 2011-10-05 ルネサスエレクトロニクス株式会社 データ処理装置
CN101689106B (zh) 2007-06-12 2013-10-09 松下电器产业株式会社 多处理器控制装置、多处理器控制方法以及多处理器控制电路
US8627327B2 (en) * 2007-10-24 2014-01-07 International Business Machines Corporation Thread classification suspension
JP5053109B2 (ja) * 2008-01-23 2012-10-17 株式会社日立製作所 制御装置
CN101499021A (zh) * 2008-01-31 2009-08-05 国际商业机器公司 在多个虚拟机上动态分配资源的方法和装置
US8468533B2 (en) 2008-04-28 2013-06-18 Panasonic Corporation Virtual machine control device, method, and program wherein a switching task used to switch to the highest priority virtual machines is the highest priority task in the current virtual machine and the virtual machine that is the switching target
JP2009294712A (ja) * 2008-06-02 2009-12-17 Panasonic Corp 優先度制御装置及び優先度制御方法
JP5323828B2 (ja) * 2008-06-24 2013-10-23 パナソニック株式会社 仮想計算機制御装置、仮想計算機制御プログラム及び仮想計算機制御回路
US8635621B2 (en) * 2008-08-22 2014-01-21 International Business Machines Corporation Method and apparatus to implement software to hardware thread priority
US8424007B1 (en) * 2008-09-30 2013-04-16 Symantec Corporation Prioritizing tasks from virtual machines
US9086913B2 (en) * 2008-12-31 2015-07-21 Intel Corporation Processor extensions for execution of secure embedded containers
JP4897851B2 (ja) * 2009-05-14 2012-03-14 インターナショナル・ビジネス・マシーンズ・コーポレーション コンピュータ・システム及びコンピュータ・システムの制御方法
US20110117944A1 (en) * 2009-11-17 2011-05-19 Yaxin Cao Method and system for task-level access arbitration between virtual modems in a multi-sim multi-standby communication device
CN102667725B (zh) * 2010-01-13 2015-09-16 马维尔以色列(M.I.S.L.)有限公司 用于媒体处理的硬件虚拟化
US20110219373A1 (en) * 2010-03-02 2011-09-08 Electronics And Telecommunications Research Institute Virtual machine management apparatus and virtualization method for virtualization-supporting terminal platform
US8341643B2 (en) * 2010-03-29 2012-12-25 International Business Machines Corporation Protecting shared resources using shared memory and sockets
WO2011148563A1 (ja) * 2010-05-24 2011-12-01 パナソニック株式会社 情報処理システム
JP5612681B2 (ja) 2010-05-24 2014-10-22 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 仮想計算機システム、領域管理方法、及びプログラム
JP5323103B2 (ja) * 2010-09-03 2013-10-23 三菱電機株式会社 グラフィカルユーザインタフェース装置
EP2622483A4 (en) * 2010-09-28 2014-06-04 Siemens Ag ADAPTIVE REMOTE CONTROL OF ROLLING EQUIPMENT
US8407710B2 (en) * 2010-10-14 2013-03-26 International Business Machines Corporation Systems and methods for dynamically scanning a plurality of active ports for priority schedule of work
WO2012086106A1 (ja) * 2010-12-21 2012-06-28 パナソニック株式会社 仮想計算機システム及び仮想計算機システム制御方法
WO2012102002A1 (ja) 2011-01-24 2012-08-02 パナソニック株式会社 仮想計算機システム、仮想計算機制御方法、仮想計算機制御プログラム、記録媒体、及び集積回路
JP2012185541A (ja) * 2011-03-03 2012-09-27 Denso Corp 車載装置、スケジューリングプログラム、及びスケジューリング方法
JP5648544B2 (ja) 2011-03-15 2015-01-07 富士通株式会社 スケジューリングプログラム、および情報処理装置
WO2012147252A1 (ja) 2011-04-27 2012-11-01 パナソニック株式会社 仮想計算機システム、仮想計算機制御方法、仮想計算機制御プログラム、及び半導体集積回路
US10417018B2 (en) 2011-05-27 2019-09-17 Microsoft Technology Licensing, Llc Navigation of immersive and desktop shells
US8924885B2 (en) 2011-05-27 2014-12-30 Microsoft Corporation Desktop as immersive application
US9843665B2 (en) 2011-05-27 2017-12-12 Microsoft Technology Licensing, Llc Display of immersive and desktop shells
KR101801359B1 (ko) * 2011-07-28 2017-11-24 엘지전자 주식회사 이동 단말기
TWI496083B (zh) * 2011-08-30 2015-08-11 Compal Electronics Inc 雙作業系統的操作方法、可攜式電子裝置以及對接擴充系統
TWI497419B (zh) 2011-10-20 2015-08-21 Via Tech Inc 電腦裝置及其中斷任務分配方法
JP5729266B2 (ja) * 2011-11-15 2015-06-03 富士通株式会社 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム
WO2013132648A1 (ja) * 2012-03-09 2013-09-12 パイオニア株式会社 情報処理装置、情報処理方法、情報処理プログラムが記録された記録媒体及び情報処理プログラム
JPWO2013132648A1 (ja) * 2012-03-09 2015-07-30 パイオニア株式会社 情報処理装置、情報処理方法、情報処理プログラムが記録された記録媒体及び情報処理プログラム
WO2013159289A1 (en) * 2012-04-25 2013-10-31 Hewlett-Packard Development Company Switching of operating systems
US9575760B2 (en) * 2013-05-17 2017-02-21 Nvidia Corporation Techniques for sharing priorities between streams of work and dynamic parallelism
US9830178B2 (en) 2014-03-06 2017-11-28 Intel Corporation Dynamic reassignment for multi-operating system devices
US9606833B2 (en) * 2014-04-09 2017-03-28 Samsung Electronics Co., Ltd Method and apparatus for providing a preemptive task scheduling scheme in a real time operating system
US10394602B2 (en) * 2014-05-29 2019-08-27 Blackberry Limited System and method for coordinating process and memory management across domains
US20160055031A1 (en) * 2014-11-13 2016-02-25 Mediatek Inc. Dual-System Architecture With Fast Recover And Switching Of Operating System
CN104506563B (zh) * 2015-01-20 2018-09-07 宇龙计算机通信科技(深圳)有限公司 进程的访问控制方法、访问控制***和终端
EP3553659B1 (en) * 2015-02-24 2022-11-23 Huawei Technologies Co., Ltd. Multi-operating system device, notification device and methods thereof
JP6110969B2 (ja) * 2016-02-24 2017-04-05 パイオニア株式会社 情報処理装置、情報処理方法、情報処理プログラムが記録された記録媒体及び情報処理プログラム
JP6615726B2 (ja) * 2016-09-16 2019-12-04 株式会社東芝 情報処理装置、情報処理方法及びプログラム
CN106547628B (zh) * 2016-11-29 2020-05-01 北京元心科技有限公司 多***的资源释放方法及装置
JP7010014B2 (ja) * 2018-01-18 2022-01-26 株式会社デンソー スケジューリング装置
US10725941B2 (en) 2018-06-30 2020-07-28 Western Digital Technologies, Inc. Multi-device storage system with hosted services on peer storage devices
US10877810B2 (en) * 2018-09-29 2020-12-29 Western Digital Technologies, Inc. Object storage system with metadata operation priority processing

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4481583A (en) * 1981-10-30 1984-11-06 At&T Bell Laboratories Method for distributing resources in a time-shared system
US5392409A (en) * 1984-01-18 1995-02-21 Hitachi, Ltd. I/O execution method for a virtual machine system and system therefor
JPS62231339A (ja) * 1986-03-31 1987-10-09 Fuji Electric Co Ltd ２つのオペレ−テイングシステムの並行動作方法
EP0427067A3 (en) * 1989-11-08 1991-08-14 Siemens Aktiengesellschaft Method for the alternating operation of a computer with several operating systems
JPH04367037A (ja) * 1991-06-13 1992-12-18 Mitsubishi Electric Corp 計算機システム
JPH05108380A (ja) * 1991-10-21 1993-04-30 Mitsubishi Electric Corp データ処理システム
JPH0799501B2 (ja) * 1991-11-18 1995-10-25 インターナショナル・ビジネス・マシーンズ・コーポレイション 複数アプリケーションの同時実行装置
JPH05197577A (ja) * 1992-01-20 1993-08-06 Nec Corp 仮想計算機システムにおける仮想計算機実行プライオリティ制御方式
US5333319A (en) * 1992-03-02 1994-07-26 International Business Machines Corporation Virtual storage data processor with enhanced dispatching priority allocation of CPU resources
JPH064310A (ja) 1992-06-24 1994-01-14 Nec Software Ltd 複数オペレーティングシステム切換え方式
US5483647A (en) * 1992-12-17 1996-01-09 Bull Hn Information Systems Inc. System for switching between two different operating systems by invoking the server to determine physical conditions to initiate a physical connection transparent to the user
JP3349547B2 (ja) * 1993-05-10 2002-11-25 株式会社日立製作所 スケジューリングシステム
JP3658420B2 (ja) * 1994-04-14 2005-06-08 株式会社日立製作所 分散処理システム
CA2173695A1 (en) * 1995-04-14 1996-10-15 Panagiotis Kougiouris Method and system for providing interoperability among processes written to execute on different operating systems
US6678712B1 (en) * 1996-01-19 2004-01-13 International Business Machines Corporation Method and system for executing a program under one of a plurality of mutually exclusive operating environments
US5826081A (en) * 1996-05-06 1998-10-20 Sun Microsystems, Inc. Real time thread dispatcher for multiprocessor applications
AU4353297A (en) * 1996-09-17 1998-04-14 Radisys Corporation Method and apparatus for encapsulating a protected-mode operating system within a real-time, protected-mode operating system
US6658447B2 (en) * 1997-07-08 2003-12-02 Intel Corporation Priority based simultaneous multi-threading
FI108478B (fi) * 1998-01-21 2002-01-31 Nokia Corp Sulautettu jõrjestelmõ
US6157989A (en) * 1998-06-03 2000-12-05 Motorola, Inc. Dynamic bus arbitration priority and task switching based on shared memory fullness in a multi-processor system
JP3659062B2 (ja) * 1999-05-21 2005-06-15 株式会社日立製作所 計算機システム
US6715016B1 (en) * 2000-06-01 2004-03-30 Hitachi, Ltd. Multiple operating system control method
EP1298624A4 (en) * 2000-06-20 2004-10-13 Hitachi Ltd VEHICLE CONTROL DEVICE

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100731983B1 (ko) * 2005-12-29 2007-06-25 전자부품연구원 저전력 무선 디바이스 프로세서용 하드와이어드 스케줄러및 스케줄링 방법

Also Published As

Publication number Publication date
JP4072271B2 (ja) 2008-04-09
ATE444523T1 (de) 2009-10-15
EP1031924B1 (en) 2009-09-30
TW490638B (en) 2002-06-11
JP2000242512A (ja) 2000-09-08
CN1264078A (zh) 2000-08-23
EP1031924A3 (en) 2003-10-15
DE60043032D1 (de) 2009-11-12
US20050149933A1 (en) 2005-07-07
KR100759280B1 (ko) 2007-09-17
EP1031924A2 (en) 2000-08-30
US7810096B2 (en) 2010-10-05

Similar Documents

Publication Publication Date Title
KR100759280B1 (ko) 복수의 오퍼레이팅 시스템을 실행하는 계산기
US8505012B2 (en) System and method for scheduling threads requesting immediate CPU resource in the indexed time slot
US9798595B2 (en) Transparent user mode scheduling on traditional threading systems
US7698540B2 (en) Dynamic hardware multithreading and partitioned hardware multithreading
US20060130062A1 (en) Scheduling threads in a multi-threaded computer
US7412590B2 (en) Information processing apparatus and context switching method
US8321874B2 (en) Intelligent context migration for user mode scheduling
KR101680109B1 (ko) 복수 코어 장치 및 그의 로드 조정 방법
JP2006515690A (ja) 複数のプロセッサを有するデータ処理システムと、複数のプロセッサを有するデータ処理システムのためのタスクスケジューラと、タスクスケジューリングの対応する方法
JP2000330806A (ja) 計算機システム
JP2004326754A (ja) 共用リソースを使用するための仮想計算機の管理
JP2000330807A (ja) 複数のプロセッサで同時にスレッドの実行を開始させる方法及びその装置並びにコンピュータ可読記録媒体
CN104272256A (zh) 任务处理装置
US7664823B1 (en) Partitioned packet processing in a multiprocessor environment
US20150052529A1 (en) Efficient task scheduling using a locking mechanism
US7111182B2 (en) Thread scheduling mechanisms for processor resource power management
EP1693743A2 (en) System, method and medium for using and/or providing operating system information to acquire a hybrid user/operating system lock
US20080256542A1 (en) Processor
US20080134187A1 (en) Hardware scheduled smp architectures
US6981258B1 (en) Process scheduler without long overhead and large memory and scheduling method used therein
JPH05108380A (ja) データ処理システム
JP2005173643A (ja) コンピュータシステム及びそのオペレーティング方法
JPS62179035A (ja) ジャーナル版数更新方法
Steiner Extending multiprogramming to a DMPP
JP2513811B2 (ja) 入出力制御方式

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
G170 Re-publication after modification of scope of protection [patent]
FPAY Annual fee payment

Payment date: 20120821

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20130819

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20140826

Year of fee payment: 8

LAPS Lapse due to unpaid annual fee