JP2017123190A - Task processing device - Google Patents
Task processing device Download PDFInfo
- Publication number
- JP2017123190A JP2017123190A JP2017043612A JP2017043612A JP2017123190A JP 2017123190 A JP2017123190 A JP 2017123190A JP 2017043612 A JP2017043612 A JP 2017043612A JP 2017043612 A JP2017043612 A JP 2017043612A JP 2017123190 A JP2017123190 A JP 2017123190A
- Authority
- JP
- Japan
- Prior art keywords
- task
- processor
- circuit
- system call
- processing
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
Images
Landscapes
- Executing Machine-Instructions (AREA)
Abstract
Description
この発明は、OS(Operating System)の機能に関し、特に、マルチプロセッサに対応したOSに関する。 The present invention relates to an OS (Operating System) function, and more particularly to an OS compatible with a multiprocessor.
パーソナルコンピュータのような汎用機器用のOSに限らず、携帯電話のような専用機器用のOSにも高度な機能が求められつつある。特に、1つのCPU(Central Processing Unit)で複数のタスクを実行可能なOS(以下、このようなタイプのOSのことを「マルチタスクOS」ともよぶ)が多くの電子機器に搭載されるようになってきている。 Advanced functions are being demanded not only for OSs for general-purpose devices such as personal computers but also for OSs for dedicated devices such as mobile phones. In particular, an OS capable of executing a plurality of tasks with a single CPU (Central Processing Unit) (hereinafter, this type of OS is also referred to as a “multitask OS”) is installed in many electronic devices. It has become to.
マルチタスクOSは、CPUの処理時間を単位時間(タイムスライス)に分割し、複数のタスクにタイムスライスを順番に割り当てる。各タスクは、OSからタイムスライスを与えられたときだけCPUを使用できる。各タイムスライスにおいては一つのタスクが実行される。タイムスライスはユーザからみて非常に短い時間なので、複数のタスクはあたかも同時実行されているかのようにみえる。このような処理方法によれば、タスクAが入力待機状態に至りCPUの処理能力を当面必要としなくなったとき、別のタスクBに実行権を与えることでCPUの処理能力を有効活用できる。ここでいう実行権とは、CPUの使用権と同義である。 The multitask OS divides the processing time of the CPU into unit times (time slices) and assigns time slices to a plurality of tasks in order. Each task can use the CPU only when a time slice is given from the OS. One task is executed in each time slice. Since time slices are very short from the user's point of view, it looks as if multiple tasks are being executed simultaneously. According to such a processing method, when the task A reaches an input standby state and does not require the CPU processing capability for the time being, the processing capability of the CPU can be effectively utilized by giving another task B the execution right. The execution right here is synonymous with the right to use the CPU.
マルチタスクOSがタスクの実行権の切り換えることを「タスクスイッチ」とよぶ。タスクスイッチは、タイムスライスが経過したときや、タスクが所定命令を実行したときに発生する。マルチタスクOSは、タスクスイッチの実行タイミングに至ると、実行中のタスクのコンテキスト情報をTCB(Task Control Block)に退避させる。コンテキスト情報とは、タスク実行時においてCPUのレジスタに格納されていたデータやタスクの実行状態に関するデータである。TCBとは、タスク固有の情報を保持するためにメモリに確保される領域である。マルチタスクOSは、実行中のタスクのコンテキスト情報をTCBに退避させたあと、次に実行権を割り当てるタスクを選択し、そのタスクのTCBからコンテキスト情報を読み出して、CPUレジスタにロードする。このようにして、各タスクはタイムスライスを単位として少しずつ自己の処理を進めていく。 Switching the task execution right by the multitasking OS is called “task switch”. A task switch occurs when a time slice elapses or when a task executes a predetermined instruction. When the task switch execution timing is reached, the multitask OS saves the context information of the task being executed in a TCB (Task Control Block). The context information is data related to the execution state of a task or data stored in a CPU register at the time of task execution. The TCB is an area secured in the memory for holding task-specific information. After saving the context information of the task being executed to the TCB, the multitask OS selects the next task to which the execution right is assigned, reads the context information from the TCB of the task, and loads it into the CPU register. In this way, each task advances its own processing little by little in units of time slices.
マルチタスクOSは、複数のタスクを効率的に実行できるというメリットがあるが、コンテキスト情報の退避・ロードというオーバーヘッドが新たに発生するというデメリットもある。通常、マルチタスクOSのメリットはタスクスイッチにともなうオーバーヘッドを補って余りある。 The multitask OS has an advantage that a plurality of tasks can be efficiently executed, but has a disadvantage that an overhead of saving / loading context information is newly generated. Usually, the merit of the multitasking OS more than compensates for the overhead associated with task switching.
近年においては、決められた時間内に処理が完了することを厳密に要求するリアルタイムOS(以下、「RTOS(Real-Time Operating System)」)が組込システム(Embeded System)を中心として普及しつつある。このような時間的要件の厳しいRTOSにおいては、タスクスイッチ時のオーバーヘッドがシステム全体のパフォーマンスに大きく影響することがある。 In recent years, a real-time OS (hereinafter referred to as “RTOS (Real-Time Operating System)”) that strictly requires completion of processing within a predetermined time has become widespread mainly in an embedded system. is there. In such an RTOS with strict time requirements, the overhead at the time of task switching may greatly affect the performance of the entire system.
本発明者は、タスクスイッチをハードウェアロジックで実現するタスク制御装置を開発した(特許文献4、5参照)。更に、本発明者は、キューの管理や割り込み処理をハードウェアロジックで実現することにも成功した(特許文献6、7参照)。これらの発明群により、タスクスイッチにともなうオーバーヘッドが大きく削減された。
The inventor has developed a task control device that implements a task switch with hardware logic (see
ただし、マルチタスクOSとはいっても、CPUが単一である限り複数のタスクを擬似的に同時実行しているにすぎない。以下、単一のCPUで動作するシステムのことを「SPシステム(Single-Processor System)」とよび、SPシステムに対応するRTOSのことを「SPRTOS」とよぶことにする。 However, even though it is a multitasking OS, as long as there is a single CPU, a plurality of tasks are simply executed simultaneously. Hereinafter, a system operating with a single CPU is referred to as an “SP system (Single-Processor System)”, and an RTOS corresponding to the SP system is referred to as “SPRTOS”.
一方、複数のCPUにより複数のタスクを真に同時実行させるというアプローチも徐々に浸透しつつある。以下、複数のCPUを同時動作させるシステムを「MPシステム(Multi-Processors System)」とよぶ。また、MPシステムに対応するRTOSを「MPRTOS」とよぶことにする。 On the other hand, an approach of executing a plurality of tasks truly simultaneously by a plurality of CPUs is gradually spreading. Hereinafter, a system that operates a plurality of CPUs simultaneously is referred to as an “MP system (Multi-Processors System)”. An RTOS corresponding to the MP system is referred to as “MPRTOS”.
MPシステムにおいては、複数のCPUがデータを安全に共有するための排他制御が必要となる。アプリケーションによっては排他制御にともなうオーバーヘッド(実行コスト)が大きくなりすぎてしまうため、期待するほどスループットが向上しない、あるいは、SPシステムよりもむしろスループットが悪化することすらある。本発明者は、上述のタスク制御回路の設計思想をMPシステムにも応用できれば、排他制御にともなうオーバーヘッドも削減できるのではないかと考えた。 In the MP system, exclusive control is necessary for a plurality of CPUs to share data safely. Depending on the application, the overhead (execution cost) associated with the exclusive control becomes too large, so that the throughput does not improve as expected, or the throughput rather deteriorates rather than the SP system. The present inventor has thought that if the design concept of the task control circuit described above can be applied to an MP system, the overhead associated with exclusive control can be reduced.
本発明は、本発明者による上記着目に基づいて完成されたものであり、その目的は、MPシステムにおいてより効率的にタスクを実行制御するための技術を提供することであり、特に、排他制御にともなうオーバーヘッドを削減する技術、を提供することにある。 The present invention has been completed on the basis of the above-mentioned attention by the present inventor, and an object thereof is to provide a technique for performing and controlling tasks more efficiently in the MP system, and in particular, exclusive control. It is to provide a technique for reducing the overhead accompanying the above.
本発明のある態様は、タスク処理装置である。
このタスク処理装置は複数のプロセッサと接続され、複数のプロセッサにおいて実行される複数のタスクの実行状態を一元的に管理する。プロセッサは、システムコール命令を実行するとき、システムコール信号をタスク制御回路に送信する。
タスク制御回路は、あるプロセッサAからシステムコール信号を受信したとき、プロセッサAのプロセッサIDとそのプロセッサAで実行中のタスクのタスクIDを登録されているプロセッサ管理情報を参照することによりプロセッサAにおいて実行中のタスクT1を特定し、READY(レディ)状態で待機中のタスクから次に実行対象となるタスクT2を自律的に選択し、タスクT1の処理データをプロセッサAの処理レジスタから所定の記憶領域に退避させ、タスクT2の処理データをプロセッサAの処理レジスタにロードさせ、プロセッサ管理情報を更新することにより、プロセッサAのタスクスイッチを実行する。
One embodiment of the present invention is a task processing device.
This task processing apparatus is connected to a plurality of processors and centrally manages the execution states of a plurality of tasks executed by the plurality of processors. When the processor executes a system call instruction, it sends a system call signal to the task control circuit.
When the system control signal is received from a certain processor A, the task control circuit refers to the processor management information in which the processor ID of the processor A and the task ID of the task being executed by the processor A are registered. The task T1 being executed is identified, the task T2 to be executed next is autonomously selected from the tasks waiting in the READY state, and the processing data of the task T1 is stored in a predetermined memory from the processing register of the processor A The task switch of the processor A is executed by saving to the area, loading the processing data of the task T2 into the processing register of the processor A, and updating the processor management information.
本実施形態によれば、タスク実行主体であるCPUなどのプロセッサとは別のハードウェアであるタスク制御回路がMPRTOSとして機能する。タスク処理装置は、プロセッサやソフトウェアからの指示に基づいてタスクを選択するのではなく、自らが内蔵するハードウェアロジックにより自律的にタスクを選択する。プロセッサ管理情報には、各プロセッサにおけるタスクの実行状況が登録されているため、タスク制御回路は各プロセッサの状態をリアルタイムにて監視できる。 According to this embodiment, a task control circuit that is hardware different from a processor such as a CPU that is a task execution entity functions as an MPRTOS. The task processing device does not select a task based on an instruction from a processor or software, but autonomously selects a task by its own hardware logic. Since the task management status is registered in the processor management information, the task control circuit can monitor the status of each processor in real time.
なお、以上の構成要素の任意の組合せ、本発明を方法やシステムにより表現したものもまた、本発明の態様として有効である。 It should be noted that any combination of the above-described components and a representation of the present invention by a method or system are also effective as an aspect of the present invention.
本発明によれば、MPシステムにおいてより効率的なタスクの実行制御が実現される。 According to the present invention, more efficient task execution control is realized in the MP system.
本実施例のタスク処理装置100は、MPシステムにおけるタスクスケジューリングと排他制御を電子回路により実現し、その処理効率を向上させている。
まず、SPシステムのタスクスケジューリングを電子回路により実現するタスク処理装置100を「基本例」として説明する。次に、仮想キューアルゴリズムの実装方法を「仮想キュー実装例」、ハードウェア主導による割込処理の実装方法を「HW割込実装例」として説明する。以上の3例を説明したあと、MPシステムを対象としたタスク処理装置100を「MP実装例」として説明する。
以下、「本実施例」というときには、原則として、「基本例」、「仮想キュー実装例」、「HW割込実装例」および「HW割込実装例」全体を示すものとする。
{基本例(SPシステム)}
The
First, the
Hereinafter, when referring to “this embodiment”, in principle, the “basic example”, “virtual queue implementation example”, “HW interrupt implementation example”, and “HW interrupt implementation example” are shown.
{Basic example (SP system)}
本実施例に示すタスク処理装置100は、マルチタスクOSのタスクスケジューリング機能を電子回路により実現している。タスク処理装置100の詳細を説明する前に、まず図1に関連してタスクの状態遷移について説明する。ここでは一般的なマルチタスクOSにおけるタスクの状態遷移として説明するが、タスク処理装置100によるタスクの状態遷移についても同じである。また、タスク処理装置100において実行されるシステムコールについても概説する。図2および図3に関連して一般的なマルチタスクOSの設計思想について述べた上で、図4から図10に関連して、基本例におけるタスク処理装置100の処理方法について詳述する。更に、セマフォ(Semaphore)やミューテックス(Mutex)、イベントなどに関する処理についても、適宜、一般的な技術と比較しながらタスク処理装置100の特徴を説明していく。
[タスクの状態遷移]
The
[Task state transition]
図1は、タスクの状態遷移図である。
マルチタスク処理において、各タスクは「状態(ステート)」を持つ。各タスクは、後述する複数の状態間を遷移し、常に、いずれかの状態となっている。状態遷移の契機となるのは、「システムコールの実行」と「割り込み要求信号の検出」である。システムコールとは各タスクが実行する命令のうちの特別な命令である。割り込み要求信号とは、キーボードの押下やマウスのクリック、通信データの受信など、周辺機器から所定データを受け取ったときに発生する信号である。もちろん、各タスクに割り当てられるタイムスライスが消費されたときにも状態遷移が発生する。
FIG. 1 is a task state transition diagram.
In multitask processing, each task has a “state”. Each task transits between a plurality of states described later, and is always in one of the states. The trigger for the state transition is “execution of system call” and “detection of interrupt request signal”. A system call is a special instruction among instructions executed by each task. The interrupt request signal is a signal generated when predetermined data is received from a peripheral device, such as a keyboard press, a mouse click, or communication data reception. Of course, the state transition also occurs when the time slice allocated to each task is consumed.
タスクは「一般タスク」と「特殊タスク」の2種類に大別される。一般タスクとは、システムコールを契機として実行される通常のタスクである。特殊タスクは、割り込み要求信号の検出を契機として実行されるタスクである。いわゆる割り込みハンドラである。まず、各タスク状態について述べた後、各種システムコール命令について説明する。 Tasks are roughly classified into two types: “general tasks” and “special tasks”. A general task is a normal task that is executed in response to a system call. The special task is a task that is executed when an interrupt request signal is detected. This is a so-called interrupt handler. First, after describing each task state, various system call instructions will be described.
(1)STOP状態(休止状態)
タスクが休止状態にあることを示す。一般タスクも特殊タスクもSTOP状態となり得る。以下、STOP状態にあるタスクのことを「STOP−タスク」とよぶ。
1−1.一般タスク
他のタスクが別のタスクの起動を指示するシステムコール(以下、「起動システムコール」とよぶ)を実行すると、STOP状態にある一般タスクは後述のREADY状態に遷移する。
1−2.特殊タスク
特殊タスクは、通常、STOP状態にある。後述のタスク切換回路210により割り込み要求信号が検出されると、特殊タスクはSTOP状態から後述のRUN状態に遷移する。このときRUN状態にあったタスクは入れ替わりにREADY状態に遷移する。
(1) STOP state (resting state)
Indicates that the task is in a dormant state. Both general tasks and special tasks can be in the STOP state. Hereinafter, a task in the STOP state is referred to as “STOP-task”.
1-1. General Task When another system executes a system call instructing activation of another task (hereinafter referred to as “activation system call”), the general task in the STOP state transitions to the READY state described later.
1-2. Special tasks Special tasks are usually in the STOP state. When an interrupt request signal is detected by a
(2)RUN状態(実行状態)
タスクが実行中であることを示す。すなわち、タスクがタイムスライスを割り当てられ、CPUの使用権を取得している状態である。一般タスクも特殊タスクもRUN状態となり得る。以下、RUN状態にあるタスクのことを「RUN−タスク」とよぶ。複数のタスクのうち、RUN状態になることができるタスクは常に1つだけであり、同時に2つのタスクがRUN状態となることはできない。
2−1.一般タスク
RUN状態にある一般タスクは、所定のシステムコールを実行するとRUN状態からREADY状態または後述するWAIT状態に遷移する。RUN状態にある一般タスクは、タイムスライスを消費したときにも、READY状態に遷移する。いずれの場合においても、RUN状態にあった一般タスクの代わりに、READY状態にある一般タスクがRUN状態に遷移する。割り込み要求信号が検出されると、RUN−タスクはREADY状態に遷移する。このときには、STOP状態にある特殊タスクがRUN状態に遷移する。
RUN−タスクが自らを終了させるシステムコール(以下、「終了システムコール」とよぶ)を実行すると、RUN−タスクはSTOP状態に遷移する。
2−2.特殊タスク
割り込み要求信号によりSTOP状態からRUN状態に遷移した特殊タスクは、自処理が完了するとSTOP状態に戻る。特殊タスクが取り得る状態はSTOP状態とRUN状態のみである。
(2) RUN state (execution state)
Indicates that the task is running. That is, the task is assigned a time slice and has acquired the right to use the CPU. Both general and special tasks can be in the RUN state. Hereinafter, a task in the RUN state is referred to as “RUN-task”. Of the plurality of tasks, only one task can be in the RUN state at any one time, and two tasks cannot be in the RUN state at the same time.
2-1. General Task A general task in the RUN state transitions from the RUN state to the READY state or a WAIT state described later when a predetermined system call is executed. A general task in the RUN state also transitions to the READY state when the time slice is consumed. In any case, instead of the general task that was in the RUN state, the general task that is in the READY state transitions to the RUN state. When an interrupt request signal is detected, the RUN-task transitions to the READY state. At this time, the special task in the STOP state transitions to the RUN state.
When the RUN-task executes a system call that terminates itself (hereinafter referred to as “end system call”), the RUN-task transitions to the STOP state.
2-2. Special task The special task that has transitioned from the STOP state to the RUN state by the interrupt request signal returns to the STOP state when its own processing is completed. The states that the special task can take are only the STOP state and the RUN state.
(3)READY状態(実行可能状態)
タスクが実行可能な状態にあることを示す。READY状態にあるタスクは、OSから実行権を与えられればいつでもRUN状態に遷移できる。一般タスクのみREADY状態となり得る。以下、READY状態にあるタスクのことを「READY−タスク」とよぶ。
RUN状態にある一般タスクがシステムコールの実行によりRUN状態以外の状態に遷移するとき、または、RUN状態にある特殊タスクが自らの処理を終了してSTOP状態に遷移するとき、READY−タスクが入れ替わりにRUN状態に遷移する。一般タスクは、READY状態からのみRUN状態に遷移する。READY状態にあるタスクが複数存在するときには、コンテキスト情報の一部であるタスク優先順位に基づいて、いずれか一つのREADY−タスクがRUN状態に遷移する。タスク優先順位が同じとなるREADY−タスクが複数存在するときには、READY状態に移行したのが最も古いタスクがRUN状態に遷移する。
(3) READY state (executable state)
Indicates that the task is ready to run. A task in the READY state can transition to the RUN state at any time if an execution right is given from the OS. Only general tasks can be in the READY state. Hereinafter, a task in the READY state is referred to as “READY-task”.
When a general task in the RUN state transitions to a state other than the RUN state by executing a system call, or when a special task in the RUN state ends its processing and transitions to the STOP state, the READY-task is switched. Transition to the RUN state. The general task changes from the READY state only to the RUN state. When there are a plurality of tasks in the READY state, one of the READY-tasks transitions to the RUN state based on the task priority that is part of the context information. When there are a plurality of READY-tasks having the same task priority, the task having the oldest transition to the READY state transitions to the RUN state.
(4)WAIT状態(待機状態)
タスクが所定のWAIT解除条件の成立を待っている状態を示す。WAIT解除条件が成立すると、WAIT状態にあるタスクはREADY状態に遷移する。一般タスクのみWAIT状態となり得る。以下、WAIT状態にあるタスクのことを「WAIT−タスク」とよぶ。WAIT解除条件に関しては後に詳述する。
(4) WAIT state (standby state)
The task is waiting for a predetermined WAIT cancellation condition to be satisfied. When the WAIT cancellation condition is satisfied, the task in the WAIT state transitions to the READY state. Only general tasks can be in the WAIT state. Hereinafter, a task in the WAIT state is referred to as “WAIT-task”. The WAIT cancellation condition will be described in detail later.
以上をまとめると、各タスクはRUN状態にあるときだけCPUを使って自らの処理を進めることができる。RTOSは、複数のタスクの状態を管理しながら、適宜、RUN−タスクを切り換える。これにより、CPUが常時いずれかのタスクを実行する処理形態が実現される。
[システムコール]
In summary, each task can proceed with its own processing using the CPU only when it is in the RUN state. The RTOS switches RUN-tasks as appropriate while managing the states of a plurality of tasks. As a result, a processing mode in which the CPU always executes one of the tasks is realized.
[System Call]
次に、システムコールについて付言しておく。システムコールは、「起動系」、「WAIT系」、「SET系」の3種類に大別される。
(1)起動系システムコール
STOP状態とREADY状態の間の遷移に関連するシステムコールである。
1−1.起動システムコール
RUN−タスクであるタスクAが別の一般タスクBを起動させるシステムコールである。このとき、STOP状態にある一般タスクBはREADY状態に遷移する。
1−2.終了システムコール
このシステムコールを実行したタスクは、自己の処理を終了させ、RUN状態からSTOP状態に遷移する。終了システムコールは、あるタスクが別のタスクを終了させる命令であってもよい。
(2)WAIT系システムコール
RUN状態とWAIT状態の間の遷移に関連するシステムコールである。
2−1.ウェイトセマフォシステムコール
セマフォ(後述)の獲得を要求するシステムコールである。
2−2.ウェイトミューテクスシステムコール
ミューテクス(後述)の獲得を要求するシステムコールである。
2−3.ウェイトイベントシステムコール
イベント(後述)の成立を待つシステムコールである。イベントIDのほか、待機フラグパターン(後述)やフラグ条件(後述)を変数として実行される。
いずれの場合においても、WAIT系システムコールにより、さまざまなWAIT解除条件が設定される。WAIT系システムコールの実行時において、既にWAIT解除条件が成立する状況にあるときには、システムコールを実行したRUN−タスクはREADY状態に遷移する。一方、WAIT解除条件が成立していないときには、RUN−タスクは、WAIT解除条件の成立を待機するWAIT状態に遷移する。
(3)SET系システムコール
WAIT状態とREADY状態の間の遷移に関連するシステムコールである。SET系システムコールの実行は、WAIT解除条件の成立契機となる。
3−1.リリースセマフォシステムコール
セマフォを解放するシステムコールである。
3−2.リリースミューテクスシステムコール
ミューテクスを解放するシステムコールである。
3−3.セットイベントシステムコール
イベントのカレントフラグパターン(後述)を設定するシステムコールである。
3−4.クリアフラグシステムコール
カレントフラグパターンをゼロクリアするためのシステムコールである。
本実施例においては、以上の計9種類のシステムコールを対象として説明するが、これ以外にもさまざまなシステムコールを実装可能であることはいうまでもない。
[一般的なRTOSの設計思想]
Next, I will add a note about system calls. System calls are roughly classified into three types: “activation system”, “WAIT system”, and “SET system”.
(1) Activation system call A system call related to a transition between the STOP state and the READY state.
1-1. Activation system call This is a system call in which task A, which is a RUN-task, activates another general task B. At this time, the general task B in the STOP state transitions to the READY state.
1-2. End system call The task that executed this system call ends its own processing and transitions from the RUN state to the STOP state. The end system call may be an instruction for one task to end another task.
(2) WAIT system call A system call related to a transition between the RUN state and the WAIT state.
2-1. Wait semaphore system call This system call requests acquisition of a semaphore (described later).
2-2. Wait mutex system call This system call requests acquisition of a mutex (described later).
2-3. Wait event system call A system call that waits for the establishment of an event (described later). In addition to the event ID, a standby flag pattern (described later) and a flag condition (described later) are executed as variables.
In any case, various WAIT cancellation conditions are set by the WAIT system call. If a WAIT cancellation condition is already satisfied when a WAIT system call is executed, the RUN-task that executed the system call transitions to the READY state. On the other hand, when the WAIT cancellation condition is not satisfied, the RUN-task transits to a WAIT state that waits for the WAIT cancellation condition to be satisfied.
(3) SET system call A system call related to a transition between the WAIT state and the READY state. Execution of a SET system call triggers the establishment of a WAIT cancellation condition.
3-1. Release semaphore system call This system call releases a semaphore.
3-2. Release mutex system call This system call releases a mutex.
3-3. Set event system call This system call sets the current flag pattern (described later) of an event.
3-4. Clear flag system call This system call clears the current flag pattern to zero.
In the present embodiment, the above nine types of system calls will be described, but it goes without saying that various system calls can be implemented.
[General RTOS design concept]
図2は、一般的なRTOSの概念図である。
このRTOSはマルチタスクOSである。一般的なRTOSはソフトウェアとして実現される。タスクAからタスクBへRUN−タスクを切り換える場合を例として説明する。タスクAがCPUを占有しているので、RTOSはCPUに割り込みをかけて、CPUの使用権をタスクAから取り上げる。その上で、タスクAのコンテキスト情報をTCBに退避させる。RTOSは、次のRUN−タスクとしてタスクBを選択し、タスクBのTCBからコンテキスト情報をCPUのレジスタにロードする。ロードが完了すると、RTOSはCPUの使用権をタスクBに渡す。このように、RTOSは、一時的にCPUの使用権を取得することにより、タスクAからタスクBへのタスクスイッチを実行する。特殊タスクの実行に関しても同様である。この場合にも、RUN−タスクのコンテキスト情報をTCBに退避させた後、特殊タスクにCPUの使用権を渡すことによりタスクスイッチを実現している。
RTOSは、ソフトウェアとして実現されるため、自らの処理を実行するためにはCPUの使用権を必要とする。いいかえれば、RTOSとタスクは、CPUの使用に関して競合関係にある。以下、このようにソフトウェアによって実現されるRTOSのことを「ソフトウェアRTOS」とよぶ。
FIG. 2 is a conceptual diagram of a general RTOS.
This RTOS is a multitasking OS. A general RTOS is realized as software. A case where the RUN-task is switched from task A to task B will be described as an example. Since task A occupies the CPU, the RTOS interrupts the CPU and picks up the right to use the CPU from task A. After that, the context information of task A is saved in the TCB. The RTOS selects task B as the next RUN-task and loads context information from the task B TCB into the CPU registers. When the loading is completed, the RTOS passes the right to use the CPU to task B. In this way, the RTOS executes task switching from task A to task B by temporarily acquiring the right to use the CPU. The same applies to the execution of special tasks. Also in this case, the task switch is realized by saving the context information of the RUN-task to the TCB and then passing the right to use the CPU to the special task.
Since the RTOS is realized as software, it requires the right to use the CPU in order to execute its own processing. In other words, RTOS and tasks are competing for CPU usage. Hereinafter, the RTOS realized by software in this way is referred to as “software RTOS”.
図3は、ソフトウェアRTOSが実行される一般的なCPUの回路図である。
CPU84は、メモリアクセスや命令の実行等を統括的に制御する実行制御回路90と、タスクのコンテキスト情報など各種データを格納する処理レジスタ92、演算を実行する演算回路94を含む。処理レジスタ92は複数種類のレジスタの集合であり、特殊レジスタ88と汎用レジスタ86に大別される。特殊レジスタ88は、プログラムカウンタ、スタックポインタ、フラグ等を保持するレジスタである。汎用レジスタ86は、作業用のデータを保持するレジスタであり、R0〜R15までの計16レジスタを含む。特殊レジスタ88は、ユーザ用とシステム用の2面が存在するが、汎用レジスタ86は一面のみである。以下、処理レジスタ92に格納されるデータのことを「処理データ」とよぶ。
FIG. 3 is a circuit diagram of a general CPU on which software RTOS is executed.
The
実行制御回路90は、出力セレクタ98に対する制御信号(CTRL)により、処理レジスタ92のうちの所望のレジスタの処理データを演算回路94に出力させる。演算回路94は、処理データ、すなわち、命令や変数にしたがって演算を実行する。演算結果は入力セレクタ96へ出力される。実行制御回路90は、入力セレクタ96に対する制御信号(CTRL)により、処理レジスタ92のうちの所望のレジスタに演算結果を入力する。
The
また、実行制御回路90は、CPUデータバスを介してメモリからデータを読み出し、入力セレクタ96を介して処理レジスタ92に適宜ロードする。実行制御回路90は、同じくCPUデータバスを介して処理データをメモリに適宜記録する。実行制御回路90は、特殊レジスタ88のプログラムカウンタを更新しながら、タスクを実行する。
Further, the
タスクスイッチが発生するときには、実行制御回路90は処理データをメモリ上の領域であるTCBに退避させる。仮にタスクAがシステムコールを実行し、タスクAからタスクBへのタスクスイッチが発生したとする。RTOSはシステムコール実行を契機としてCPUの使用権を取得するので、CPU84は一時的にRTOS用のプログラムにしたがって動作することになる。その処理過程は以下の通りである。
<タスクAのコンテキスト情報の退避>
When a task switch occurs, the
<Save context information of task A>
1.実行制御回路90は、特殊レジスタ88をユーザ用からシステム用に切り換える。システム用の特殊レジスタ88にはRTOS処理用の処理データがロードされている。
2.実行制御回路90は、汎用レジスタ86のデータを図示しないスタックに退避させる。
3.実行制御回路90は、図示しない記憶媒体、たとえば、別のレジスタから、RTOSのための処理データを汎用レジスタ86にロードする。この段階で、処理レジスタ92の処理データは、完全にRTOS用の処理データに入れ替わる。
4.RTOSは、メモリからタスクAのTCBを検出し、スタックに退避されている処理データをTCBに書き込む。また、ユーザ用の特殊レジスタ88の処理データもコンテキスト情報の一部としてTCBに書き込む。こうして、タスクAの処理データがTCBに退避される。RTOSは、タスクAが「RUN」から「READY(またはWAIT)」に状態遷移したことをタスクAのTCBに記録する。
<タスクBのコンテキスト情報のロード>
1. The
2. The
3. The
4). The RTOS detects the TCB of task A from the memory and writes the processing data saved in the stack to the TCB. Also, the processing data of the user
<Load context information of task B>
1.RTOSは、メモリからタスクBのTCBを検出し、TCBのコンテキスト情報をスタックと特殊レジスタ88に書き込む。RTOSは、タスクBが「READY」から「RUN」に状態遷移したことをタスクBのTCBに記録する。
2.RTOSは、RTOS処理用のデータを汎用レジスタ86から図示しない記録媒体に退避させる。
3.実行制御回路90は、スタックのコンテキスト情報を汎用レジスタ86にロードする。実行制御回路90は、特殊レジスタ88をシステム用からユーザ用に切り換える。こうして、タスクBの処理データが処理レジスタ92にロードされる。
1. The RTOS detects the task B TCB from the memory and writes the TCB context information to the stack and
2. The RTOS saves RTOS processing data from the general-
3. The
以上のような処理過程を経て、タスクスイッチが実現される。通常、汎用レジスタ86は一面構成のため、タスク用の処理データとRTOS用の処理データを切り換えるためにスタックを使っている。汎用レジスタ86も2面化すれば、スタックを介して退避・ロードする必要がなくなるため、より高速なタスクスイッチが可能である。
The task switch is realized through the above processing steps. Normally, the general-
本実施例においては、更に、タスクごとに退避レジスタ110を設けることにより、いっそう高速なタスクスイッチを実現している。退避レジスタ110を使ったタスクスイッチについては図5に関連して詳述する。図3に関連して説明したCPU84と一般的なソフトウェアRTOSの場合、タスクスイッチに際して、頻繁にTCBへのアクセスが発生していることがわかる。上記設例では、タスクAからタスクBにタスクスイッチするという前提で説明したが、実際には、RTOSが次に実行すべきタスクBを選択するためにも多くの命令を実行する必要がある。このときにも、RTOSは頻繁にメモリにアクセスすることになる。本実施例におけるタスク処理装置100は、後述のタスク制御回路200がタスク選択処理を専用に実行するため、更に高速なタスクスイッチを実現している。
[タスク処理装置100によるRTOSのハードウェア化]
In this embodiment, a
[RTOS hardware implementation by the task processing device 100]
図4は、本実施例におけるRTOSの概念図である。
一般的なソフトウェアRTOSと異なり、本実施例におけるRTOSは、主として、CPUとは別個のハードウェアとして実現される。以下、ハードウェアによって実現されるRTOSのことを、「ハードウェアRTOS」とよぶ。本実施例のRTOSは、主として、CPUとは別個のハードウェアであるため、自らの処理を実行するためにはCPUの使用権を実質的にほとんど必要としない。いいかえれば、RTOSとタスクは、CPUの使用に関してほとんど競合関係にない。図2に示した一般的なソフトウェアRTOSの場合、CPUはタスク実行用回路であるとともに、RTOS実行用回路でもあった。これに対し、本実施例におけるハードウェアRTOSの場合、CPUはタスク実行回路として明確化され、タスクスケジューリング機能は後述の退避回路120とタスク制御回路200を中心として実現することができる。
FIG. 4 is a conceptual diagram of the RTOS in this embodiment.
Unlike a general software RTOS, the RTOS in the present embodiment is mainly realized as hardware separate from the CPU. Hereinafter, RTOS realized by hardware is referred to as “hardware RTOS”. The RTOS of this embodiment is mainly hardware that is separate from the CPU, and therefore requires substantially no right to use the CPU to execute its own processing. In other words, RTOS and tasks have little competition for CPU usage. In the case of the general software RTOS shown in FIG. 2, the CPU is not only a task execution circuit but also an RTOS execution circuit. On the other hand, in the case of the hardware RTOS in this embodiment, the CPU is clarified as a task execution circuit, and the task scheduling function can be realized centering on a
図5は、基本例におけるタスク処理装置100の回路図である。
タスク処理装置100は、CPU150に加えて退避回路120とタスク制御回路200を含む。CPU150はタスクの実行主体であり、退避回路120とタスク制御回路200が図4に示したRTOSの役割を担う回路である。タスクススケジューリング処理は、タスク制御回路200により主導される。
FIG. 5 is a circuit diagram of the
The
CPU150は、実行制御回路152、処理レジスタ154および演算回路160を含む。CPU150は、図3に関連して説明した一般的なCPUであってもよい。ただし、本実施例におけるCPU150は、図3に示したCPU84とは信号線の接続方法等が若干変更されている。具体的な回路構成については次の図6に関連して詳述する。
The
タスク制御回路200は、タスク切換回路210、セマフォテーブル212、イベントテーブル214、タスク選択回路230および状態記憶部220を含む。セマフォテーブル212とイベントテーブル214については、図13以降に関連して詳述する。状態記憶部220は、タスクごとに対応づけられたユニットである。以下、タスクAに対応する状態記憶部220のことを「状態記憶部220_A」のように表記する。各状態記憶部220は、タスクの状態データを保持する。状態データとは、コンテキスト情報のうち、特に、タスク優先順位や状態など、タスクの属性を示す情報である。具体的なデータの内容については、図10に関連して後述する。各状態記憶部220からは、全タスクの全状態データがタスク選択回路230に常時出力している。タスク選択回路230は、各タスクの状態データに基づいて、RUN−タスクの選択等、各種タスク選択を行う回路である。タスク選択回路230についても図10以降に関連して詳述する。タスク切換回路210は、実行制御回路152から受信するシステムコール信号(SC)や外部装置からの割り込み要求信号(INTR)を検出すると、タスクスイッチを実行する。
The
実行制御回路152はシステムコール実行時には、システムコール信号(SC)をタスク切換回路210に送信する。また、タスク切換回路210が割り込み要求信号(INTR)を検出したときには、タスク切換回路210は実行制御回路152に対して停止要求信号(HR)をアサートする。実行制御回路152は、CPU150の動作が停止しているときには停止完了信号(HC)をタスク切換回路210にアサートする。これら3種類の信号によって、CPU150とタスク制御回路200が連係動作することになる。
The
退避回路120は、ロード選択回路112および複数の退避レジスタ110を含む。退避レジスタ110も、タスクごとに対応づけられたユニットであり、処理レジスタ154の処理データを退避させるためのレジスタである。したがって、退避レジスタ110は、処理レジスタ154と同等以上のデータ容量を持つ。以下、タスクAに対応する退避レジスタ110のことを「退避レジスタ110_A」のように表記する。ロード選択回路112は、タスク切換回路210から指示されると、いずれかの退避レジスタ110のデータ(以下、退避レジスタ110が保持するデータのことを「退避データ」とよぶ)を処理レジスタ154にロードする。
The
各退避レジスタ110はそれぞれの退避データをロード選択回路112に常時出力する。タスク切換回路210がロード選択回路112にタスクIDを指定したタスク選択信号(TS)を入力すると、ロード選択回路112は指定されたタスクに対応する退避レジスタ110の退避データを処理レジスタ154に出力する。更に、タスク切換回路210が処理レジスタ154に対して書き込み信号(WT)を入力すると、その退避データは処理レジスタ154に実際にロードされる。
Each save register 110 always outputs each save data to the
一方、処理レジスタ154の全処理データも全退避レジスタ110に常時出力されている。タスク切換回路210が所望の退避レジスタ110に対して書き込み信号(WT)をアサートすると、その退避レジスタ110に処理データが退避される。ここで、処理レジスタ154と各退避レジスタ110を接続するバスが一度に伝送可能なビット数は、処理データをパラレル転送できるように設定されている。そのため、タスク切換回路210は、退避レジスタ110に書き込み信号を一度送信するだけで、処理データを退避レジスタ110に一気に書き込むことができる。また、退避レジスタ110とロード選択回路112、ロード選択回路112とCPU150を接続するバスのビット数も同様に設定されている。
以下、システムコールと割り込み要求信号のそれぞれについてタスクスイッチの実行方法を説明する。
[1]システムコール実行
On the other hand, all the processing data in the
Hereinafter, a task switch execution method for each of the system call and the interrupt request signal will be described.
[1] System call execution
CPU150の実行制御回路152がシステムコールを実行するとき、実行制御回路152はCPU150のクロック(以下、「CPUクロック(CLK)」とよぶ)を停止させる。具体的な停止方法については、図7等に関連して後に詳述する。実行制御回路152は、システムコールの実行を示すシステムコール信号(SC)をタスク制御回路200のタスク切換回路210に送信する。また、CLKが停止完了すると、実行制御回路152は停止完了信号(HC)をタスク切換回路210にアサートする。
When the
CPU150とタスク切換回路210の間には、システムコール信号伝送用に9本の信号線が接続されている。9本の信号線は先述した9種類のシステムコールに対応する。実行制御回路152は、実行されたシステムコールの種類に応じて、いずれかのシステムコール信号線にてデジタルパルスを伝送する。タスク切換回路210は、9本のシステムコール信号線のうち、どの信号線からデジタルパルスが検出されたかに応じて、即座に実行されたシステムコールの種類を検出できる。タスク切換回路210は、システムコールの種類に応じて、タスク選択回路230の出力データから必要なデータを選択し、システムコールにより指示された処理を実行する。この処理は、HCがアサートされたことを条件として実行される。タスク切換回路210とタスク選択回路230の関係については、図10に関連して詳述する。なお、システムコールのパラメータや戻り値は、処理レジスタ154のうち、所定の汎用レジスタ158に書き込まれる。タスク切換回路210は汎用レジスタ158に対してパラメータの読み出しや戻り値の書き込みを実行可能である。ここでは、RUN−タスクであるタスクAがウェイトセマフォシステムコールを実行したとする。したがって、まず、タスクAの処理データを退避させる必要がある。
<タスクAのコンテキスト情報の退避>
Nine signal lines are connected between the
<Save context information of task A>
実行制御回路152は、ウェイトセマフォシステムコールを示すSC信号をタスク切換回路210に入力する。実行制御回路152はCLKを停止させ、停止が完了するとHCをアサートする。タスク切換回路210はタスク選択回路230に内蔵される各種選択回路のうち、後述のセマフォ選択回路234に対して待機対象となるセマフォのセマフォIDを出力した上で、次に実行すべきタスクBを選択する。タスク切換回路210は、状態記憶部220_Aに対して所定データを書き込む。たとえば、タスクAの状態として「RUN」から「READY」や「WAIT」に設定変更する。より具体的には、タスク切換回路210は、状態データのうちタスク状態を示すデータとして「WAIT」を全状態記憶部220に出力した上で、状態記憶部220_Aだけに書き込み信号(WT_A)を入力する。こうして、タスクAの状態が設定変更される。
The
次に、タスク切換回路210は、退避レジスタ110_Aに対して書き込み信号(WT)を出力する。処理レジスタ154の処理データは、常時、各退避レジスタ110に出力されているので、この書き込み信号(WT)によりタスクAの退避レジスタ110_Aに退避される。
<タスクBのコンテキスト情報のロード>
Next, the
<Load context information of task B>
タスク切換回路210は、タスクAの状態データの変更、処理データの退避が完了すると、タスクBを指定したタスク選択信号(TS_B)をロード選択回路112に出力する。これにより、退避レジスタ110_Bの退避データが処理レジスタ154に出力される。タスク切換回路210は、処理レジスタ154に書き込み信号(WT)を出力すると、タスクBの退避データが処理レジスタ154にロードされる。また、タスク切換回路210は、タスクBの状態記憶部220に対して所定データを書き込む。たとえば、タスクBの状態を「READY」から「RUN」に設定変更する。以上の処理が完了すると、実行制御回路152はCPUクロックを再開させる。CPU150は、再開されたCPUクロックによりタスクBの実行を開始する。処理方法の更なる詳細については、図8(b)に関連して後述する。
[2]割り込み要求信号の発生
The
[2] Generation of interrupt request signal
タスク切換回路210は周辺機器からの割り込み要求信号(INTR)を検出する。より具体的には、割り込み要求信号(INTR)は、図示しない割込コントローラからタスク切換回路210に送信される。割り込み要求信号(INTR)のレベルを示すパラメータは、割込コントローラが内蔵するレジスタに記録される。タスク切換回路210は実行制御回路152に停止要求信号(HR)をアサートし、実行制御回路152はCPUクロックを停止させる。システムコール実行時と同様、タスク切換回路210はRUN−タスクの処理データを退避レジスタ110に退避させる。次に、タスク切換回路210は特殊タスクを起動する。割り込み要求信号のパラメータに関わらず起動される特殊タスクは1種類である。特殊タスクは、割込コントローラの内蔵レジスタからINTRのパラメータを読み出し、パラメータに応じた処理を実行する。特殊タスクが実行する処理は、セットイベントシステムコールやセットセマフォシステムコールの実行かもしれないし、一般タスクの起動かもしれない。パラメータによっては、特殊タスクは特段の処理を実行せずに終了するかもしれない。INTRのパラメータによってどのような処理を実行するかは特殊タスクの実装による。特殊タスクが実行終了すると、READY−タスクの中から次のRUN−タスクが選択される。
The
タスク切換回路210は、特殊タスクに対応した退避レジスタ110の処理データをCPU150にロードさせる。このような一般タスクから特殊タスクへの切り換えのために要する時間は、タスク制御回路200の動作クロックによってあらかじめ見積もることができる。HRを実行制御回路152にアサートしてからタスク切換回路210の動作クロックが所定クロック分経過すると、タスク切換回路210はCPUクロックの停止を解除するためにHRをネゲートする。実行制御回路152はHRをネゲートされるとCPUクロックを再開させる。このときには、タスク切換回路210によって一般タスクから特殊タスクへのタスクスイッチが完了している。処理方法の詳細については、図8(a)に関連して後述する。
The
いずれの場合においても、
(A)処理データの退避・ロード
(B)タスクの状態遷移およびRUN−タスクの選択
というタスクスイッチの中核となる処理をハードウェアにより実現している。(A)および(B)に関し、メモリ上のTCBにアクセスする必要がなくなることもタスクスイッチの高速化に寄与している。また、タスク処理装置100を実現するにあたり、CPU150については、CPUクロックを停止および再開する機能を追加するだけでよい。なお、これらの機能がすべてハードウェアによって実現されることは、本発明の範囲を限定するものではない。たとえば、(A)または(B)の主たる機能をハードウェアにより実現し、ハードウェアの機能を補助するためにRTOSの一部の機能をソフトウェアで実現してもよいことは当業者には理解されるところである。
In either case,
(A) Saving / loading of processing data (B) The core processing of task switching such as task state transition and RUN-task selection is realized by hardware. Regarding (A) and (B), the need to access the TCB on the memory is eliminated, which contributes to the speedup of the task switch. In realizing the
図6は、図5のCPU150の回路図である。
図3のCPU84と異なり、処理レジスタ154は特殊レジスタ156と汎用レジスタ158共に一面だけの構成となっている。処理レジスタ154にはそれぞれロード選択回路112からの入力バス、退避レジスタ110への出力バス、タスク切換回路210からの書き込み信号(WT)用の信号線が追加されている。実行制御回路152は、出力セレクタ164に対する制御信号(CTRL)により、処理レジスタ92のうちの所望のレジスタのデータを演算回路160に入力する。演算結果は入力セレクタ162への入力となる。実行制御回路152は、入力セレクタ162に対する制御信号(CTRL)により、処理レジスタ154のうちの所望のレジスタに演算結果を入力する。実行制御回路152は、特殊レジスタ156のプログラムカウンタを更新しながら、タスクを実行する。
FIG. 6 is a circuit diagram of the
Unlike the
処理データは、メモリ上のTCBではなく退避レジスタ110に退避される。処理レジスタ154からは常時、各退避レジスタ110に処理データが出力されている。実際にどの退避レジスタ110にどのタイミングで処理データを退避させるかは、先述のようにタスク切換回路210によって制御される。
The processing data is saved in the
処理レジスタ154には、メモリ上のTCBではなく退避レジスタ110から退避データがロードされる。実際にどの退避レジスタ110の処理データをどのタイミングでロードするかは、先述のようにタスク切換回路210によって制御される。
The save data is loaded into the
処理レジスタ154とロード選択回路112、処理レジスタ154と退避レジスタ110を接続するバスは、一度に処理データをパラレル転送可能なビット数のバスである。そのため、タスク切換回路210による書き込み信号(WT)により、一度に読み出しや書き込みが可能となっている。一般的なソフトウェアRTOSは、タスクスイッチに際しては処理レジスタ154を一時的に占有する必要がある。これに対して、本実施例におけるハードウェアRTOSは、タスクスイッチ処理のための特別な処理データを処理レジスタ154にロードする必要がない。タスクAからタスクBの切り換えに際しては、タスクAの処理データを退避したあとにタスクBの処理データをロードするだけなので、処理レジスタ154をシステム用とユーザ用の2面分用意したり、スタックを介したデータの入れ替え処理を実行する必要がない。
The bus connecting the
図7は、実行制御回路152がCPUクロックを停止させる仕組みを示す回路図である。
第2ANDゲート174の入力は原クロック(CLK0)と第1ANDゲート172の出力で、後者は負論理である。第1ANDゲート172の出力は停止完了信号(HC)である。停止完了信号(HC)は通常は0なので、第2ANDゲート174は、入力された原クロック(CLK0)をCPUクロック(CLK)としてそのまま出力する。CPU150は、第2ANDゲート174の出力するCPUクロックを受けて動作する。第1ANDゲート172の出力が「1」のとき、いいかえれば、停止完了信号(HC)=1のときには、第2ANDゲート174の出力はゼロに固定され、CPUクロック(CLK)が停止する。
FIG. 7 is a circuit diagram showing a mechanism by which the
The inputs of the second AND
第1ANDゲート172の入力は、ORゲート176の出力とCPUビジー信号(CBUSY)で、後者は負論理である。CBUSYは、CPU150の内部サイクルを発生させる既知のステートマシンから出力される信号であり、CPU150が停止可能な状態にあるときに「1」となる信号である。たとえば、演算回路94が実行中の単一の命令またはロックされている複数の命令の最後の命令を完了させ、CPUが停止可能な状態になったとき、または、既にCPUクロックの供給が停止されているときに「0」となる。
The inputs of the first AND
ORゲート176の入力は、命令復号器170の出力(SC_DETECT)とタスク切換回路210からの停止要求信号(HR)である。命令復号器170は、SC_DETECTを保持するラッチ回路を内蔵する。命令復号器170は、CPU150からフェッチされたデータ(FD)を入力とし、FDがシステムコール命令のときにSC_DETECT=1を出力する。内蔵ラッチ回路により、その後にFDが変化しても、命令復号器170はSC_DETECT=1を継続して出力する。命令復号器170にはタスク切換回路210の処理レジスタ154に対する書き込み信号(WT)も入力される。WTが0から1に変化するとき、先述したように退避データの処理レジスタ154へのロードが実行される。このWTは所定時間後に1から0に戻るパルス信号である。WTが1から0に変化するとき、命令復号器170のラッチ回路はリセットされ、命令復号器170はSC_DETECTをネゲートする。SC_DETECTと書き込み信号(WT)の関係については、図8(b)に関連して詳述する。本実施例における命令復号器170は、実行対象命令がシステムコールか否かを判定するために実行制御回路152に専用に設けられる装置である。変形例として、命令復号器170はCPU150のデコードステージを担当するCPUデコーダと共通化されてもよい。この場合、命令復号器170は、CPUデコーダに、復号したデータがシステムコール命令であったときにSC_DETECT=1を出力する機能を追加することにより実現できる。
割り込み要求信号(INTR)が発生したとき、タスク切換回路210は実行制御回路152に停止要求信号(HR)をアサートする。すなわち、ORゲート176の出力は、システムコールが実行されるか、停止要求信号(HR)がアサートされたときに「1」となる。
The inputs of the
When the interrupt request signal (INTR) is generated, the
まとめると、システムコールが実行されるか割り込み要求信号が発生し、かつ、CPUビジー信号が「0」となったとき、第1ANDゲート172の出力は「1」となり、第2AND174からはCPUクロックが出力されなくなる。
In summary, when a system call is executed or an interrupt request signal is generated and the CPU busy signal becomes “0”, the output of the first AND
図8(a)は、割り込み要求信号発生時における各種信号の関係を示すタイムチャートである。
同図においては、まず、時刻t0において、タスク切換回路210は外部からの割り込み要求信号(INTR)を検出している。タスク切換回路210は、特殊タスクを実行させるため、実行制御回路152に停止要求信号(HR)をアサートする。入力タイミングt1は、検出タイミングt0とほとんど同時である。時刻t1では、CPU150のステートマシンは「タスク実行中」であり、CBUSY=1である。HR=1より、ORゲート176は「1」を出力するが、CBUSY=1ゆえにCPU150は停止しない。そのため、HR=1が入力されても、しばらくはCPUクロック(CLK)は原クロック(CLK0)に同期して出力される。
FIG. 8A is a time chart showing the relationship between various signals when an interrupt request signal is generated.
In the figure, first, at time t0, the
時間が経過し、時刻t2においてCBUSY=0に変化している。既にHR=1のため、第1ANDゲート172はHC=1を出力し、第2ANDゲート174から出力されるCPUクロックは0に固定される。一方、タスク切換回路210は、HCがアサートされたことを契機として、一般タスクから特殊タスクへタスクスイッチを開始する。詳しくは後述するが、このタスクスイッチのために要する時間はタスク制御回路200の動作クロックにして数回分である。HCがアサートされてから、タスク制御回路200の動作クロックが所定回数変化したことを条件として(時刻t3)、タスク制御回路200は停止要求信号(HR)をネゲートする。HR=0なので、実行制御回路152はCPUクロック(CLK)を再開させる。CPU150が処理を再開すると、CPU150はCBUSYを0から1に変化させる(時刻t4)。このように、CPUクロックが停止する時刻t2から時刻t3の間に、一般タスクから特殊タスクへのタスクスイッチが実行されることになる。
なお、別の処理方法として、タスク制御回路200の動作クロックが所定回数変化したことを条件とする代わりに、タスク制御回路200がタスクスイッチを完了させたことを条件として、HRをネゲートしてもよい。そして、実行制御回路152が、HRがネゲートされたことを条件として、HCをネゲートさせてもよい。HC=0となると、実行制御回路152はCPUクロック(CLK)を再開させる。こうして、タスクの実行を再開させてもよい。
Time has passed, and CBUSY = 0 has been changed at time t2. Since HR = 1 already, the first AND
As another processing method, HR may be negated on the condition that the
図8(b)は、システムコール実行時における各種信号の関係を示すタイムチャートである。
同図においては、まず、時刻t0において、命令復号器170がシステムコールを検出し、SC_DETECTを0から1に変化させている。時刻t0では、CPU150のステートマシンは「タスク実行中」であり、CBUSY=1である。SC_DETECT=1より、ORゲート176は「1」を出力するが、CBUSY=1ゆえにCPU150は停止しない。そのため、SC_DETECT=1が出力されても、しばらくはCPUクロック(CLK)は原クロック(CLK0)に同期して出力される。
FIG. 8B is a time chart showing the relationship between various signals when a system call is executed.
In the figure, first, at time t0, the
時間が経過し、時刻t1においてCBUSY=0に変化している。SC_DETECT=1、かつ、CBUSY=1となったので、HCはネゲートされ、CPUクロックは停止される。タスク切換回路210は、HC=0を入力されると、タスクスイッチ処理を開始し、書き込み信号(WT)をCPU150に出力する。WTが0から1に変化する時刻t2に退避データが処理レジスタ154にロードされる。書き込み信号(WT)は、パルス信号のため、所定時間経過後の時刻t3にWT=0となる。このWT:1→0の立ち下がり検出により命令復号器170にラッチされているSC_DETECTはリセットされる(時刻t4)。このとき、CBUSYは0から1に変化する。CBUSY=1となったので、HC=0となり、CPUクロックが再開される。CPUクロックが停止する時刻t1から時刻t4の間に、タスクスイッチが実行されることになる。
なお、別の処理方法として、WT:1→0の立ち下がり検出を条件とする代わりに、タスク制御回路200がタスクスイッチを完了させ、HRをネゲートしたことを条件として、実行制御回路152が、HCをネゲートしてもよい。HC=0となったことを条件として、SC_DETECTをリセットする。実行制御回路152はCPUクロック(CLK)を再開させ、CBUSYは0から1に変化する。
Time has passed, and at time t1, CBUSY = 0. Since SC_DETECT = 1 and CBUSY = 1, HC is negated and the CPU clock is stopped. When HC = 0 is input,
As another processing method, the
いずれの場合においても、CPU150は、CPUクロックが停止している期間にRUN−タスクの切り換えが行われたことを認識する必要はない。タスク切換回路210は、CPUクロックが停止し、CPU150がいわばフリーズしている間にタスクスイッチ処理を行うため、CPU150の処理とタスク制御回路200の処理はシーケンシャルに分離されている。
In any case, the
図9は、パイプライン処理におけるCPUクロックの停止タイミングを説明するための模式図である。
CPU150は、複数の命令をメモリから処理レジスタ154に順次読み出しながら実行することにより、タスクを実行する。このタスクの実行単位である命令は、以下の4つのフェーズに分解される。
1.F(フェッチ):メモリから命令を取り出す。
2.D(デコード):命令を解釈する。
3.E(エグゼキューション):命令を実行する。
4.WB(ライトバック):実行結果をメモリに書き込む。
FIG. 9 is a schematic diagram for explaining the stop timing of the CPU clock in the pipeline processing.
The
1. F (fetch): fetch an instruction from the memory.
2. D (decode): interprets an instruction.
3. E (execution): execute an instruction.
4). WB (write back): The execution result is written in the memory.
あるタスクが命令1から命令5を順次実行する場合、命令1のFからWBまで実行した後、命令2のFを実行してもよい。しかし、より効率的な実行のために、命令1の実行中に命令2の実行を開始することが多い。このような処理方法は、パイプライン処理とよばれる。たとえば、命令1が、Dのフェーズに至ったとき、命令2のFのフェーズを開始する。命令1が、Eのフェーズに至ったときには、命令2のDフェーズ、命令3のFフェーズを実行する。このように、単位時間当たりに実行される命令の数を増やすことにより、タスクごとの実行時間を減少させることができる。
When a certain task sequentially executes
更に、各フェーズを2つのフェーズに細分化してもよい。たとえば、FフェーズをF1:F2という2つのフェーズに分離される。命令1が、F2のフェーズに至ったとき、命令2のF1のフェーズを開始する。命令1が、D1のフェーズに至ったときには、命令2のF2フェーズ、命令3のF1フェーズを実行する。フェーズの細分化により、いっそうCPU150の計算資源を効率的に利用できる。図9においては、各フェーズを2つのフェーズに細分化して実行するパイプライン処理において、システムコールが発生したときのCPUクロック停止タイミングについて説明する。
Furthermore, each phase may be subdivided into two phases. For example, the F phase is separated into two phases F1: F2. When
同図において、命令1はCPUクロック「0」のタイミングで処理を開始されている。CPUクロック「4」のタイミングで、命令1のデコードが完了する。命令1はシステムコールであったとする。命令復号器170はSC_DETECTを0から1に変化させる。次にSC_DETECTが1から0に戻る条件は、タスク切換回路210から処理レジスタ154への書き込み信号(WT)が1から0に変化することである。SC_DETECT=1となっても、命令2〜5が既に実行中または実行開始済であるため、CBUSY=1のままである。そのため、第2ANDゲート174はCPUクロックを引き続き出力することになる。ただし、実行制御回路152は、SC_DETECT=1のときには、新たな命令がフェッチされないようにプログラムカウンタの更新を一時停止させる。したがって、命令6以降はメモリからフェッチされなくなる。
In the figure,
CPUクロック「8」のタイミングで命令1は実行完了するが、命令2〜5は実行中であるため、CPUビジー信号は「1」のままである。CPUクロック「12」のタイミングに至ると命令5が実行完了する。このとき、CPUビジー信号は「0」となる。あとは、図8(b)に関連したプロセスにしたがって、CPUクロックの供給が停止される。タスク切換回路210は、命令5まで終了した段階の処理データを退避レジスタ110に退避させる。このような停止方法によれば、システムコールが実行されたあとの命令の実行結果を無駄にすることなくタスクスイッチできる。タスクスイッチが完了すると、CPUビジー信号は再び「1」にセットされ、命令復号器170の処理も再開される。こうして、CPUクロックが再び供給されるようになる。
なお、別の処理方法として、システムコール命令が実行完了するタイミングで、CPUビジー信号を「0」とし、CPUクロックの供給を停止してもよい。この場合、システムコール命令と同時に実行されていた別の命令は実行途中のまま停止する。中途停止された命令の中間的な処理結果は処理レジスタ154に記録されたあと、退避レジスタ110に退避される。次回、このタスクがRUN−タスクとなるときには、中途停止された命令の続きが実行される。たとえば、ある命令が、フェッチを終了した段階で中途停止された場合、メモリから読み出された命令やオペランドは退避レジスタ110に退避される。タスク再開時には、退避レジスタ110のデータが処理レジスタ154にロードされ、デコードステージから続きの処理が実行されることになる。
Although the
As another processing method, the CPU busy signal may be set to “0” and the supply of the CPU clock may be stopped when the execution of the system call instruction is completed. In this case, another instruction that has been executed simultaneously with the system call instruction is stopped during execution. The intermediate processing result of the interrupted instruction is recorded in the
図10は、状態記憶部220とタスク切換回路210の関係を示す回路図である。
状態記憶部220は、状態レジスタ250とタイマ252を含む、状態記憶部220は、タスクの状態データを保持する。また、タイマ252は、タスクがREADY状態またはWAIT状態に遷移したときに開始するタイマである。タスクがREADY状態に遷移してから経過した時間のことを「READY経過時間」、タスクがWAIT状態に遷移してから経過した時間のことを「WAIT経過時間」とよぶ。タイマ252は、その値をTIM信号として常時出力する。タスク切換回路210は、タスクスイッチに際して、あるタスクがREADY状態またはWAIT状態に変化したときには、そのタスクのタイマ252を駆動して時間計測を開始させる。
FIG. 10 is a circuit diagram showing the relationship between the
The
状態記憶部220は、以下に示すレジスタの集合である。
(A)タスクIDレジスタ254:タスクIDを保持する。タスクIDレジスタ254からはタスクIDを示すID信号がタスク選択回路230に常時出力される。以下、タスクAのタスクIDレジスタ254からタスク選択回路230に出力されるID信号のことを「ID_A信号」と表記する。状態記憶部220から出力される他の信号についても同様である。
(B)タスク優先順位レジスタ256:タスク優先順位を保持する。タスク優先順位レジスタ256からはタスク優先順位を示すPR信号が常時出力される。「0」が最高優先順位であり、値が大きいほどタスク優先順位が低いことを示す。
(C)タスク状態レジスタ258:タスク状態を示す。STOP、READY、RUN、WAIT、IDLEのいずれかがST信号として常時出力される。なお、IDLEとは、タスクが初期化される前の状態である。
(D)タスク起動アドレスレジスタ260:メモリにおけるタスクのTCBアドレスを示す。出力はAD信号である。
(E)待機理由レジスタ262:タスクがWAIT状態にあるとき、WAIT解除条件の一部として待機の理由を示す。待機理由は、「セマフォ待ち」、「イベント待ち」、「ミューテックス待ち」のいずれかである。出力はWR信号である。
(F)セマフォIDレジスタ264:タスクがセマフォ待ちを理由として、WAIT状態にあるとき、待ち対象のセマフォ(以下、単に「待機セマフォ」)のセマフォIDを保持する。出力はSID信号である。
(G)ミューテックスIDレジスタ265:タスクがミューテックス待ちを理由として、WAIT状態にあるとき、待ち対象のミューテックス(以下、単に「待機ミューテックス」)のミューテックスIDを保持する。出力はMID信号である。
(H)イベントIDレジスタ266:タスクがイベント待ちを理由として、WAIT状態にあるとき、待ち対象のイベント(以下、単に「待機イベント」)のイベントIDを保持する。出力はEID信号である。
(I)待機フラグレジスタ268:タスクがイベント待ちを理由として、WAIT状態にあるとき、待機フラグパターンを保持する。出力はFL信号である。
(J)フラグ条件レジスタ270:タスクがイベント待ちを理由として、WAIT状態にあるとき、フラグ条件を保持する。出力はFLC信号である。待機フラグパターンやフラグ条件については後述する。
(K)フラグ初期化レジスタ272:待機フラグパターンの有無を示すデータを保持する。出力はFLI信号である。
(L)タイムアウトカウンタ274:WAIT系システムコールにおいてはタイムアウト値が変数として指定される。タイムアウトカウンタ274は、タイムアウト値を保持する。タスク切換回路210は、各タイムアウトカウンタ274のタイムアウト値を定期的にデクリメントする。出力はTO信号である。タスク切換回路210がタイムアウト値をデクリメントする代わりに、タイムアウトカウンタ274自体が自律的に自らのタイムアウト値を定期的にデクリメントしてもよい。
The
(A) Task ID register 254: Holds a task ID. An ID signal indicating a task ID is constantly output from the task ID register 254 to the
(B) Task priority order register 256: Holds task priority order. The task priority order register 256 always outputs a PR signal indicating the task priority order. “0” is the highest priority, and a larger value indicates a lower task priority.
(C) Task status register 258: indicates a task status. Any one of STOP, READY, RUN, WAIT, and IDLE is always output as the ST signal. Note that IDLE is a state before the task is initialized.
(D) Task activation address register 260: indicates the TCB address of the task in the memory. The output is an AD signal.
(E) Wait reason register 262: When the task is in the WAIT state, it indicates the reason for waiting as part of the WAIT cancellation condition. The reason for waiting is one of “waiting for semaphore”, “waiting for event”, and “waiting for mutex”. The output is a WR signal.
(F) Semaphore ID register 264: Holds the semaphore ID of the semaphore to be waited (hereinafter simply referred to as “waiting semaphore”) when the task is in the WAIT state because of waiting for the semaphore. The output is a SID signal.
(G) Mutex ID register 265: Holds the mutex ID of the mutex to be waited (hereinafter simply referred to as “waiting mutex”) when the task is in the WAIT state because of waiting for the mutex. The output is a MID signal.
(H) Event ID register 266: Holds an event ID of an event to be waited (hereinafter simply referred to as “waiting event”) when the task is in the WAIT state because of waiting for an event. The output is an EID signal.
(I) Wait flag register 268: Holds a wait flag pattern when the task is in the WAIT state because of waiting for an event. The output is the FL signal.
(J) Flag condition register 270: Holds a flag condition when the task is in the WAIT state because of waiting for an event. The output is an FLC signal. The standby flag pattern and flag conditions will be described later.
(K) Flag initialization register 272: Holds data indicating the presence or absence of a standby flag pattern. The output is the FLI signal.
(L) Timeout counter 274: In a WAIT system call, a timeout value is specified as a variable. The
タスク選択回路230は、各状態記憶部220から出力される各種信号をもとに、タスクの選択を行う。タスク選択回路230は、以下に示す回路を含む。
(A)実行選択回路232:タスクスイッチに際して、次のRUN−タスクを選択する。実行選択回路232は、状態記憶部220から常時出力される状態データにより常にいずれかのタスクをRUN−タスクとして選択している。実行選択回路232の入力信号は、ID、ST、PR、TIMの4種類である。出力は、次のRUN−タスクのタスクIDである。詳細な回路構成については図12に関連して詳述する。
(B)セマフォ選択回路234:リリースセマフォシステムコールの実行により、WAIT状態からREADY状態に遷移すべきタスクを選択する。リリースセマフォシステムコールにより解放されるセマフォ(以下、単に「解放セマフォ」)のセマフォIDをタスク切換回路210から入力される。状態記憶部220からの入力信号は、ID、ST、WR、PR、SID、TIMの6種類である。出力信号は、WAIT状態からREADY状態に遷移するタスクのタスクIDである。該当するタスクが存在しなければ、−1などの所定値を出力する。より具体的な回路構成については図13に関連して詳述する。
(C)イベント選択回路236:セットイベントシステムコールの実行により、WAIT状態からREADY状態に遷移するタスクを選択する。セットイベントシステムコールによりセットされるイベント(以下、単に「設定イベント」)のイベントIDをタスク切換回路210から入力される。状態記憶部220からの入力信号は、ID、ST、WR、EID、FL、FLCの6種類である。出力信号は、WAIT状態からREADY状態に遷移するタスクのタスクIDと、そのタスクのFL、FLCを出力する。
(D)タイムアウト検出回路238:WAIT状態のタスクのうち、タイムアウトカウンタ274のタイムアウト値がゼロとなったタスクを検出する。タイムアウト検出回路238は、タイムアウト値が更新されるごとに駆動される。タイムアウト検出回路238の入力信号は、ID、ST、TOの3種類である。出力信号は、該当するタスクのタスクIDである。該当するタスクが存在しなければ、−1などの所定値を出力する。
(E)ミューテックス回路240:リリースミューテックスシステムコールの実行により、WAIT状態からREADY状態に遷移するタスクを選択する。リリースミューテックスシステムコールにより解放されるミューテックス(以下、単に「解放ミューテックス」)のミューテックスIDをタスク切換回路210から入力される。状態記憶部220からの入力信号は、ID、ST、WR、PR、SID、TIMの6種類である。出力信号は、WAIT状態からREADY状態に遷移するタスクのタスクIDである。該当するタスクが存在しなければ、−1などの所定値を出力する。
(F)検索回路242:タスク切換回路210からタスクIDを入力されると、そのタスクの全状態データを出力する。
The
(A) Execution selection circuit 232: When the task is switched, the next RUN-task is selected. The
(B) Semaphore selection circuit 234: Selects a task to transition from the WAIT state to the READY state by executing a release semaphore system call. A semaphore ID of a semaphore released by a release semaphore system call (hereinafter simply “release semaphore”) is input from the
(C) Event selection circuit 236: Selects a task that transitions from the WAIT state to the READY state by executing the set event system call. An event ID of an event (hereinafter simply referred to as “setting event”) set by the set event system call is input from the
(D) Timeout detection circuit 238: Among the tasks in the WAIT state, a task for which the timeout value of the
(E) Mutex circuit 240: Selects a task that transitions from the WAIT state to the READY state by executing the release mutex system call. The mutex ID of the mutex released by the release mutex system call (hereinafter simply referred to as “release mutex”) is input from the
(F) Search circuit 242: When a task ID is input from the
以下においては、タスクスイッチに関連し、RUN−タスクの選択、セマフォ、イベント、ミューテックス、タイムアウトについて、特に、タスク選択回路230の処理を中心として一般的な技術と比較しながら説明する。
[RUN−タスク選択]
[1]一般的なソフトウェアRTOSによるRUN−タスクの選択
In the following, regarding the task switch, RUN-task selection, semaphore, event, mutex, and timeout will be described in comparison with a general technique, particularly focusing on the processing of the
[RUN-task selection]
[1] Selection of RUN-task by general software RTOS
図11は、一般的なRTOSによるRUN−タスク選択に際して利用されるタスクレディリストを示す図である。
タスクレディリストは、メモリ上に形成され、各READY−タスクのTCBをポインタによって連結したリストである。優先順位ポインタ280は、タスク優先順位ごとに設けられ、該当タスク優先順位のタスクのTCBの先頭アドレスを指す。同図のタスクレディリストの場合、タスク優先順位「0」の優先順位ポインタ280は、タスクAのTCBをアドレスし、タスク優先順位「1」の優先順位ポインタ280は、タスクBのTCBをアドレスしている。タスクAのTCBは、更に、タスクDのTCBをアドレスしている。 一般的なソフトウェアRTOSは、このタスクレディリストを走査しながら、次のRUN−タスクを選択する。このとき、RTOSは、
A.RUN−タスクをRUNからREADYに状態遷移させる。
B.次のRUN−タスクを選択し、そのタスクのタスク状態をREADYからRUNに状態遷移させる。
という2段階の処理を行う。ソフトウェアRTOSによる各処理を分解すると以下の通りである。
<RUN−タスクの状態遷移>
FIG. 11 is a diagram showing a task ready list used when selecting a RUN-task by a general RTOS.
The task ready list is formed on a memory and is a list in which TCBs of each READY-task are linked by pointers. The
A. RUN--Transitions the task from RUN to READY.
B. The next RUN-task is selected, and the task state of the task is changed from READY to RUN.
A two-stage process is performed. Each processing by the software RTOS is disassembled as follows.
<RUN-task state transition>
ここでは、RUN−タスクをタスクJとして説明する。
A1.RTOSは、RUN−タスクのタスクIDをメモリに保持している。このタスクIDをもとに、タスクJのTCBのアドレスを取得する。
A2.TCBにアクセスし、タスクJのタスク優先順位を取得する。タスク優先順位は「0」であったとする。
A3.図11に示すタスクレディリストのうち、タスクJのタスク優先順位に対応する優先順位ポインタ280を取得する。
A4.取得した優先順位ポインタ280が示すTCBを検出する。ここではタスクAのTCBが検出される。
A5.タスクAのTCBが持つポインタをたどっていき、最後尾のTCBを検出する。同図においては、タスクFが最後尾である。
A6:タスクFのTCBのポインタがタスクJのTCBをアドレスするように設定する。こうして、タスクJのTCBがタスクレディリストに追加される。
A7.タスクJのTCBに「READY」を設定する。また、処理データは、TCBのレジスタ格納エリアにコピーされる。
<READY−タスクの状態遷移>
Here, RUN-task is described as task J.
A1. The RTOS holds the task ID of the RUN-task in the memory. Based on this task ID, the TCB address of task J is acquired.
A2. Access TCB and obtain task priority of task J. It is assumed that the task priority is “0”.
A3. A
A4. The TCB indicated by the acquired
A5. Traces the pointer of the task A TCB and detects the last TCB. In the figure, task F is the last.
A6: The task F TCB pointer is set to address the task J TCB. In this way, the TCB of task J is added to the task ready list.
A7. “READY” is set in the TCB of task J. Further, the processing data is copied to the register storage area of the TCB.
<READY-task state transition>
B1.RTOSは、タスク優先順位「0」の優先順位ポインタ280がいずれかのTCBを示しているか検出する。TCBがなければ、タスク優先順位「1」の優先順位ポインタ280がいずれかのTCBを示しているか検出する。TCBが見つかるまで、タスク優先順位を下げながらいずれかのタスクを特定する。同図の場合、タスクAが特定されることになる。
B2.タスクAをタスクレディリストからはずす。具体的には、タスク順位「0」の優先順位ポインタ280がタスクAではなくタスクDのTCBをアドレスするように書き換える。また、タスクAのポインタがタスクDをアドレスしないようにNULL設定する。こうして、タスクAのTCBがタスクレディリストから外される。
B3.タスクAのTCBに「RUN」を設定する。また、タスクAのTCBのレジスタ格納エリアに退避されていた処理データが処理レジスタにロードされる。
B1. The RTOS detects which TCB the
B2. Remove task A from the task ready list. Specifically, the
B3. “RUN” is set in the TCB of task A. Further, the processing data saved in the TCB register storage area of task A is loaded into the processing register.
一般的なソフトウェアRTOSは、このようなタスクレディリストによりタスクスイッチを行う。すなわち、RTOSが複数のREADY−タスクの中からRUN−タスクを選択するポリシは以下の通りである。
1.READY−タスクであること(第1条件)。
2.READY−タスクのうち、最もタスク優先順位の高いタスクであること(第2条件)。
3.最もタスク優先順位の高いタスクが複数存在するときには、READY状態になった時期が最も古いタスクであること(第3条件)。
このような3つの条件のことを、まとめて「RUNタスク選択条件」とよぶことにする。タスク処理装置100の実行選択回路232は、このようなRTOSのタスクスケジューリング機能をハードウェアにより実現している。
[2]基本例のハードウェアRTOSによるRUN−タスクの選択
A general software RTOS performs task switching by such a task ready list. That is, the policy for RTOS to select a RUN-task from a plurality of READY-tasks is as follows.
1. READY-task (first condition).
2. READY-task having the highest task priority (second condition).
3. When there are a plurality of tasks having the highest task priority, the task in the READY state is the oldest task (third condition).
These three conditions are collectively referred to as “RUN task selection conditions”. The
[2] RUN-task selection by hardware RTOS in basic example
図12は、実行選択回路232の回路図である。
ここでは、タスク0〜タスク7の8つのタスクから、RUN−タスクを選択するとして説明する。実行選択回路232は、4つの第1比較回路290(290a〜290d)、2つの第2比較回路292(292a、292b)、1つの第3比較回路294を含む。また、8つの判定回路296(296a〜296h)も含む。
判定回路296は、タスクの状態を示すST信号を入力とし、READYであれば「1」、READY以外であれば「0」を示すCID信号を出力する。判定回路296は、上記RUNタスク選択条件のうちの第1条件に基づく判定を行っている。第1比較回路290は、2つのタスクのID、PR、TIM、および、判定回路296からのCID信号を入力とする。
FIG. 12 is a circuit diagram of the
Here, a description will be given assuming that a RUN-task is selected from eight tasks of
The determination circuit 296 receives the ST signal indicating the task state, and outputs a CID signal indicating “1” if READY and “0” if not READY. The determination circuit 296 performs determination based on the first condition among the RUN task selection conditions. The first comparison circuit 290 receives the IDs of the two tasks, PR, TIM, and the CID signal from the determination circuit 296 as inputs.
第1比較回路290aに着目して説明する。第1比較回路290aは、タスク0とタスク1を比較し、上記したRUNタスク選択条件に基づいて、より好適なタスクを選択する。
第1の判定:まず、判定回路296aと判定回路296bのそれぞれから出力されるCID信号を比較する。いずれか一方が「1」であれば、いいかえれば、いずれか一方のタスクだけがREADY状態であれば、第1比較回路290aは、そのタスクのID、PR、TIMを出力する。いずれも「0」であれば、すなわち、いずれのタスクもREADY状態でなければ、第1比較回路290aは、ID=PR=TIM=NULLを出力する。これは、いずれのタスクも選択されなかったことを示す。いすれも「1」であれば、すなわち、いずれのタスクもREADY状態であれば、次の第2の判定が実行される。
第2の判定:タスク0のPR信号とタスク1のPR信号を比較し、タスク優先順位が上位となるタスクを選択する。たとえば、タスク0のタスク優先順位が「1」、タスク1のタスク優先順位が「2」であれば、タスク0のID、PR、TIMを出力する。第2の判定により、タスク優先順位が上位のタスクがRUN−タスクの候補として選択されることになる。タスク0とタスク1のタスク優先順位が同じであれば、次の第3の判定が実行される。
第3の判定:タスク0のTIM信号とタスク1のTIM信号を比較し、READY経過時間が長い方のタスクを選択する。READY経過時間が同じであれば、タスク0を選択するものとする。経過時間の大小を比較するだけで判定できるため、タスクレディリストのようなTCBの順序管理が不要となる。
Description will be made by paying attention to the
First determination: First, the CID signals output from the
Second determination: The PR signal of
Third determination: The
このようにして、タスク0とタスク1、タスク2とタスク3、タスク4とタスク5、タスク6とタスク7がそれぞれRUNタスク選択条件により比較される。第2比較回路292は、2つの第1比較回路290からの出力により、更にRUN−タスクの候補を絞り込む。第2比較回路292aは、第1比較回路290aと第1比較回路290bの出力によりタスク選択を実行する。このため、第2比較回路292aは、タスク0〜タスク3のうち、最もRUNタスク選択条件に適合するタスクのID、PR、TIMを出力する。第3比較回路294も同様であり、第3比較回路294はタスク0〜タスク7のいずれかのタスクのタスクIDを出力する。
In this way,
このような処理方法によれば、RUNタスク選択条件をハードウェアにより実現できる。一般的なソフトウェアRTOSは、タスクレディリストにアクセスしながらRUN−タスクを選択していたが、本実施例における実行選択回路232は、状態記憶部220から常時出力される状態データによりRUN−タスクを選択している。実行選択回路232の処理をまとめると以下の通りである。
<RUN−タスクの状態遷移>
According to such a processing method, the RUN task selection condition can be realized by hardware. The general software RTOS selects the RUN-task while accessing the task ready list. However, the
<RUN-task state transition>
ここでは、RUN−タスクをタスクJとして説明する。
A1.タスク切換回路210は、タスクJのタスク状態レジスタ258に「READY」を設定する。
A2.タスク切換回路210は、タスクJのタイマ252をセットしてREADY経過時間の計測を開始させる。
こうして、タスクJはRUN→READYに状態遷移する。処理データは、先述したようにタスクJの退避レジスタ110に退避される。処理レジスタ154と退避レジスタ110をつなぐバスは、処理データをパラレルに伝送可能であるため、A1とA2の処理は1クロック時間で実行可能である。
<READY−タスクの状態遷移>
Here, RUN-task is described as task J.
A1. The
A2. The
Thus, task J makes a state transition from RUN to READY. The processing data is saved in the save register 110 of the task J as described above. Since the bus connecting the
<READY-task state transition>
B1.タスク切換回路210は、タスクJの状態遷移が完了したときに実行選択回路232が出力するタスクIDから、RUN−タスクを特定する。このタスクのタスク状態レジスタ258に「RUN」を設定する。
こうして、特定されたタスクはREADY→RUNに状態遷移する。特定されたタスクの処理データは退避レジスタ110から処理レジスタ154にロードされる。退避レジスタ110と処理レジスタ154をつなぐバスも、処理データをパラレルに伝送可能なビット数であるため、B1の処理は1クロック時間で実行可能である。
B1. The
Thus, the specified task makes a state transition from READY to RUN. The processing data of the identified task is loaded from the save register 110 to the
ソフトウェアRTOSは、タスクスイッチに際して、タスクレディリストへのアクセス等によりCPUのCPUクロック時間を多く消費する。これに対し、本実施例におけるタスク制御回路200は、僅かな時間でタスクスイッチを完了させることができる。状態記憶部220は常時状態データを実行選択回路232に出力しているため、実行選択回路232は常時いずれかのタスクのタスクIDを出力している。タスクスイッチが発生してからRUN−タスクの選択処理を開始するのではなく、タスクスイッチが発生したときの実行選択回路232の出力によりRUN−タスクの選択を行う点もタスクスイッチの高速化に寄与している。ここでは、タスクが8つであるとして説明したが、比較回路の段数を増やすことにより、より多くのタスクにも対応可能である。
[セマフォ処理]
The software RTOS consumes a large amount of CPU clock time due to access to a task ready list or the like at the time of task switching. On the other hand, the
[Semaphore processing]
図13は、一般的なRTOSによるセマフォ処理において利用されるウェイトセマフォリストを示す図である。
ウェイトセマフォリストを説明する前に、セマフォについて簡単に説明する。セマフォテーブル212には、セマフォIDとセマフォカウンタが対応づけて記録される。セマフォカウンタは、初期値として有限数に設定される。たとえば、セマフォID=4、セマフォカウンタ=3として設定されているとする。いずれかのタスクがセマフォID=4のセマフォを待機セマフォとしてウェイトセマフォシステムコールを実行すると、タスク切換回路210は待機セマフォのセマフォカウンタをデクリメントする。セマフォカウンタはウェイトセマフォイベントコールにより獲得要求されるごとにデクリメントされ、0になると獲得できなくなる。セマフォカウンタが0となっているセマフォを待機セマフォとしてウェイトセマフォシステムコールを実行したタスクは、WAIT状態に状態遷移する。
FIG. 13 is a diagram showing a wait semaphore list used in semaphore processing by a general RTOS.
Before describing the wait semaphore list, a brief description of semaphores will be given. In the semaphore table 212, a semaphore ID and a semaphore counter are recorded in association with each other. The semaphore counter is set to a finite number as an initial value. For example, it is assumed that semaphore ID = 4 and semaphore counter = 3 are set. When any task executes a wait semaphore system call with the semaphore with semaphore ID = 4 as a waiting semaphore, the
一方、いずれかのタスクがセマフォID=4のセマフォを解放セマフォとしてリリースセマフォシステムコールを実行すると、タスク切換回路210はセマフォテーブル212のセマフォカウンタをインクリメントする。まとめると、
セマフォカウンタ>0のとき:ウェイトセマフォシステムコールを実行したタスクは、RUN→READYに遷移する。このときセマフォカウンタはデクリメントされる。
セマフォカウンタ=0のとき:ウェイトセマフォシステムコールを実行したタスクは、RUN→WAITに遷移する。セマフォカウンタはデクリメントされない。
ウェイトセマフォシステムコールを実行したタスクがWAIT状態からREADY状態に遷移するためには、別のタスクがリリースセマフォシステムコールを実行する必要がある。
[1]一般的なソフトウェアRTOSによるセマフォ処理
On the other hand, when any task executes a release semaphore system call with the semaphore with semaphore ID = 4 as a release semaphore, the
When semaphore counter> 0: The task that executed the wait semaphore system call transits from RUN to READY. At this time, the semaphore counter is decremented.
When semaphore counter = 0: The task that executed the wait semaphore system call transits from RUN to WAIT. The semaphore counter is not decremented.
In order for the task that executed the wait semaphore system call to transition from the WAIT state to the READY state, another task needs to execute the release semaphore system call.
[1] Semaphore processing by general software RTOS
一般的なソフトウェアRTOSはウェイトセマフォリストにより、セマフォ待ちを理由としてWAIT状態にあるタスク(以下、特に、「セマフォ待ちタスク」とよぶ)のTCBを管理する。ウェイトセマフォリストは、図11のタスクレディリストと同等の形状のリストであり、メモリ上に形成される。各セマフォ待ちタスクのTCBは、ポインタによって連結される。優先順位ポインタ280は、該当タスク優先順位のセマフォ待ちタスクのTCBの先頭アドレスを指す。
一般的なソフトウェアRTOSは、リリースセマフォシステムコールが実行されたとき、このウェイトセマフォリストを走査しながら、WAIT状態からREADY状態に遷移させるべきセマフォ待ちタスクを選択する。ウェイトセマフォシステムコールおよびリリースセマフォシステムコール実行時におけるRTOSの処理は以下の通りである。
<ウェイトセマフォシステムコールの実行>
A general software RTOS manages a TCB of a task in a WAIT state because of waiting for a semaphore (hereinafter, particularly referred to as “semaphore waiting task”) using a wait semaphore list. The wait semaphore list is a list having the same shape as the task ready list of FIG. 11, and is formed on the memory. The TCB of each semaphore waiting task is linked by a pointer. The
When a general software RTOS executes a release semaphore system call, it scans this wait semaphore list and selects a semaphore waiting task to be changed from the WAIT state to the READY state. The RTOS processing at the time of executing the wait semaphore system call and the release semaphore system call is as follows.
<Execution of wait semaphore system call>
ここでは、RUN−タスクをタスクJとして説明する。
A1.RTOSは、RUN−タスクのタスクIDをメモリに保持している。このタスクIDをもとに、タスクJのTCBのアドレスを取得する。
A2.ウェイトセマフォシステムコールにおいて指定された待機セマフォのセマフォカウンタを検出する。以下、セマフォカウンタの値に応じて処理は分岐する。
(セマフォカウンタ>0のとき)
A3.RTOSは、待機セマフォのセマフォカウンタをデクリメントする。
A4.タスクJのTCBに「READY」を設定する。この場合、タスクJのTCBはタスクレディリストに追加される。
(セマフォカウンタ=0のとき)
A3.TCBにアクセスし、タスクJのタスク優先順位を取得する。タスク優先順位は「0」であったとする。
A4.ウェイトセマフォリストのうち、タスクJのタスク優先順位に対応する優先順位ポインタを取得する。
A5.取得した優先順位ポインタが示すTCBを検出する。ここではタスクAのTCBが検出される。
A6.タスクAのTCBが持つポインタをたどっていき、最後尾のTCBを検出する。同図においては、タスクFが最後尾である。
A7:タスクFのTCBのポインタがタスクJのTCBをアドレスするように設定する。こうして、タスクJのTCBがウェイトセマフォリストに追加される。
A8.タスクJのTCBに「WAIT」を設定する。また、待機セマフォのセマフォIDも設定する。
<リリースセマフォシステムコールの実行>
Here, RUN-task is described as task J.
A1. The RTOS holds the task ID of the RUN-task in the memory. Based on this task ID, the TCB address of task J is acquired.
A2. The semaphore counter of the waiting semaphore specified in the wait semaphore system call is detected. Hereinafter, the process branches according to the value of the semaphore counter.
(When semaphore counter> 0)
A3. The RTOS decrements the semaphore counter of the standby semaphore.
A4. “READY” is set in the TCB of task J. In this case, the TCB of task J is added to the task ready list.
(When semaphore counter = 0)
A3. Access TCB and obtain task priority of task J. It is assumed that the task priority is “0”.
A4. A priority pointer corresponding to the task priority of task J is acquired from the wait semaphore list.
A5. The TCB indicated by the acquired priority order pointer is detected. Here, the TCB of task A is detected.
A6. Traces the pointer of the task A TCB and detects the last TCB. In the figure, task F is the last.
A7: The task F TCB pointer is set to address the task J TCB. Thus, the TCB of task J is added to the wait semaphore list.
A8. “WAIT” is set in the TCB of task J. A semaphore ID of the standby semaphore is also set.
<Execution of release semaphore system call>
B1.RTOSは、タスク優先順位「0」のタスクを順番にたどりながら、解放セマフォを待機セマフォとするセマフォ待ちタスクを検索する。存在しなければ、タスク優先順位「1」のタスクを検索対象とする。解放セマフォを待機セマフォとするセマフォ待ちタスクが検出されるか否かに応じて処理は分岐する。
(検出されたとき)
B2.検出されたタスクがタスクEであるとして説明する。タスクEのTCBに「READY」を設定する。また、待機セマフォのセマフォIDをクリアする。
B3.タスクEのTCBをウェイトセマフォリストから外す。
B4.セマフォを解放したタスクの状態をRUN→READYに状態遷移させる。このタスクのTCBは、タスクレディリストに追加される。
(検出されなかったとき)
B2.セマフォカウンタをインクリメントする。
B3.セマフォを解放したタスクの状態をRUN→READYに状態遷移させる。このタスクのTCBは、タスクレディリストに追加される。
B1. The RTOS searches for a semaphore waiting task with the release semaphore as a waiting semaphore while following the tasks with the task priority “0” in order. If not, the task with the task priority “1” is set as a search target. Processing branches depending on whether or not a semaphore waiting task whose release semaphore is a waiting semaphore is detected.
(When detected)
B2. A description will be given assuming that the detected task is task E. “READY” is set in the TCB of task E. Also, the semaphore ID of the standby semaphore is cleared.
B3. The task E TCB is removed from the wait semaphore list.
B4. The state of the task that has released the semaphore is changed from RUN to READY. The TCB for this task is added to the task ready list.
(When not detected)
B2. Increment the semaphore counter.
B3. The state of the task that has released the semaphore is changed from RUN to READY. The TCB for this task is added to the task ready list.
一般的なソフトウェアRTOSは、このようなウェイトセマフォリストを管理することによって、セマフォ関連処理を行う。セマフォの解放に際し、RTOSが複数のWAIT−タスクの中からREADY−タスクを選択するポリシは以下の通りである。
1.WAIT−タスクであること(第1条件)。
2.WAIT−タスクのうち、解放セマフォを待機セマフォとするタスクであること(第2条件)
3.そのようなタスクが複数存在するときには、最もタスク優先順位の高いタスクであること(第3条件)。
4.最もタスク優先順位の高いタスクが複数存在するときには、WAIT状態になった時期が最も古いタスクであること(第4条件)。
このような4つの条件のことを、まとめて「セマフォ待機解除条件」とよぶことにする。タスク処理装置100のセマフォ選択回路234は、このようなRTOSのタスクスケジューリング機能をハードウェアにより実現している。
[2]基本例のハードウェアRTOSによるセマフォ処理
A general software RTOS performs semaphore-related processing by managing such a wait semaphore list. When releasing a semaphore, the policy for RTOS to select a READY-task from a plurality of WAIT-tasks is as follows.
1. WAIT-task (first condition).
2. Of the WAIT-tasks, the task must be a release semaphore as a standby semaphore (second condition)
3. When there are a plurality of such tasks, the task has the highest task priority (third condition).
4). When there are a plurality of tasks having the highest task priority, the task that has entered the WAIT state is the oldest task (fourth condition).
These four conditions are collectively referred to as “semaphore standby release conditions”. The
[2] Semaphore processing by hardware RTOS in basic example
図14は、セマフォ選択回路234の回路図である。
ここでも、タスク0〜タスク7の8つのタスクを前提として説明する。セマフォ選択回路234は、4つの第1比較回路300(300a〜300d)、2つの第2比較回路302(302a、302b)、1つの第3比較回路304を含む。また、8つの判定回路306(306a〜306h)も含む。
判定回路306は、状態記憶部220からのST、WR、SID信号とタスク切換回路210からのセマフォIDを示す信号を入力とする回路である。ここで入力されるセマフォIDは、解放セマフォのセマフォIDである。判定回路306は、解放セマフォを待機セマフォとするセマフォ待ちタスクであれば「1」、そうでなければ「0」を示すCID信号を出力する。判定回路306は、上記セマフォ待機解除条件のうちの第1条件と第2条件に関する判定結果を出力する回路である。第1比較回路300は、2つのタスクのID、PR、TIM、および、判定回路306からのCID信号を入力とする。
FIG. 14 is a circuit diagram of the
Here, description will be made on the premise of eight tasks of
The determination circuit 306 is a circuit that receives the ST, WR, and SID signals from the
第1比較回路300は、セマフォ待機解除条件のうち第3条件と第4条件についての判定を行う回路である。第2比較回路302や第3比較回路304も同様である。既に明らかなように、RUNタスク選択条件の第2条件および第3条件は、セマフォ待機解除条件の第3条件および第4条件と同じである。実行選択回路232の各比較回路は、タスクの状態データ(PR、TIM)を比較する回路である。一方、セマフォ選択回路234の各比較回路も、タスクの状態データ(PR、TIM)を比較する回路である。したがって、実行選択回路232の第1比較回路290とセマフォ選択回路234の第1比較回路300は、同等のロジックを内蔵する回路であり、共通化することができる。各タスクは判定回路306により第1条件と第2条件を判定された上で、第1比較回路300の判定処理に供される。あとは、実行選択回路232と同等の判定処理により、いずれかのタスクIDが第3比較回路304から出力される。ウェイトセマフォシステムコールおよびリリースセマフォシステムコール実行時における処理は以下の通りである。
<ウェイトセマフォシステムコールの実行>
The first comparison circuit 300 is a circuit that performs determination on the third condition and the fourth condition among the semaphore standby cancellation conditions. The same applies to the second comparison circuit 302 and the third comparison circuit 304. As is apparent, the second condition and the third condition of the RUN task selection condition are the same as the third condition and the fourth condition of the semaphore standby cancellation condition. Each comparison circuit of the
<Execution of wait semaphore system call>
ここでは、RUN−タスクをタスクJとして説明する。
A1.タスク切換回路210は、ウェイトセマフォシステムコールにおいて指定されたセマフォのセマフォカウンタをセマフォテーブル212から検出する。以下、セマフォカウンタの値に応じて処理は分岐する。
(セマフォカウンタ>0のとき)
A2.タスク切換回路210は、セマフォテーブル212のセマフォカウンタをデクリメントする。
A3.タスクJのタスク状態レジスタ258に「READY」を設定する。このとき、タスク切換回路210は、RUN−タスクのタイマ252をセットしてREADY経過時間の計測を開始させる。
(セマフォカウンタ=0のとき)
A2.タスク切換回路210は、タスクJのタスク状態レジスタ258に「WAIT」、待機理由レジスタ262に「セマフォ待ち」、セマフォIDレジスタ264に待機セマフォのセマフォIDをセットし、タイマ252をセットしてWAIT経過時間の計測を開始させる。
こうして、ウェイトセマフォシステムコールを実行したタスクはRUN→READYまたはWAITに状態遷移する。
<リリースセマフォシステムコールの実行>
Here, RUN-task is described as task J.
A1. The
(When semaphore counter> 0)
A2. The
A3. “READY” is set in the
(When semaphore counter = 0)
A2. The
In this way, the task that executed the wait semaphore system call makes a state transition from RUN to READY or WAIT.
<Execution of release semaphore system call>
B1.タスク切換回路210は、解放セマフォのセマフォIDを各判定回路306に入力する。各判定回路306は、このセマフォIDを対象としてセマフォ待機解除条件のうちの第1条件および第2条件の成否を判定する。したがって、各第1比較回路300は、第3条件および第4条件にもとづいてタスクを選択する。
(いずれかの判定回路306が「1」を出力し、第3比較回路304がいずれかのタスクIDを出力したとき)
B2.検出されたタスクのタスク状態レジスタ258に「READY」を設定し、待機理由レジスタ262とセマフォIDレジスタ264をクリアし、タイマ252にREADY経過時間を計測させる。
B3.システムコールを実行したタスクのタスク状態レジスタ258に「READY」に設定し、READY経過時間の計測を開始する。
(いずれの判定回路306も「1」を出力せず、第3比較回路304がいずれのタスクIDも出力しないとき)
B2.タスク切換回路210はセマフォテーブル212のセマフォカウンタをインクリメントする。
B3.システムコールを実行したタスクの状態をRUN→READYに状態遷移させる。
B1. The
(When any determination circuit 306 outputs “1” and the third comparison circuit 304 outputs any task ID)
B2. “READY” is set in the
B3. The
(None of the determination circuits 306 outputs “1”, and the third comparison circuit 304 does not output any task ID)
B2. The
B3. The state of the task that executed the system call is changed from RUN to READY.
状態記憶部220は常時状態データをセマフォ選択回路234に出力しているため、タスク切換回路210がセマフォIDを判定回路306に入力すると、セマフォ選択回路234は直ちに選択処理を実行できる。
[ミューテックス処理]
Since the
[Mutex processing]
ミューテックスもセマフォと同じく、タスク間の同期処理に利用される。ミューテックスとセマフォは以下の点において相違する。
1.セマフォカウンタは1以上の整数を設定可能である。これに対し、ミューテックスはセマフォカウンタが1または0の特殊なセマフォである。セマフォカウンタが2以上のときには、同一セマフォを2以上のタスクが獲得できる。しかし、ミューテックスの場合、あるミューテックスを獲得できるタスクは常に1つだけである。
2.リリースセマフォシステムコールによりセマフォを解放できるタスクは、ウェイトセマフォシステムコールによりセマフォを獲得したタスクに限らない。これに対し、リリースミューテックスシステムコールによりミューテックスを解放できるタスクは、ウェイトミューテックスシステムコールによりミューテックスを獲得したタスクだけである。
Mutexes, like semaphores, are also used for synchronization between tasks. Mutexes and semaphores differ in the following respects.
1. The semaphore counter can set an integer of 1 or more. In contrast, a mutex is a special semaphore with a semaphore counter of 1 or 0. When the semaphore counter is 2 or more, two or more tasks can acquire the same semaphore. However, in the case of a mutex, there can always be only one task that can acquire a mutex.
2. A task that can release a semaphore by a release semaphore system call is not limited to a task that has acquired a semaphore by a wait semaphore system call. On the other hand, the task that can release the mutex by the release mutex system call is only the task that has acquired the mutex by the wait mutex system call.
ミューテックスの解放に際し、複数のWAIT−タスクの中からREADY−タスクを選択するポリシは以下の通りである。
1.WAIT−タスクであること(第1条件)。
2.WAIT−タスクのうち、解放ミューテックスを待機ミューテックスとするタスクであること(第2条件)
3.そのようなタスクが複数存在するときには、最もタスク優先順位の高いタスクであること(第3条件)。
4.最もタスク優先順位の高いタスクが複数存在するときには、WAIT状態になった時期が最も古いタスクであること(第4条件)。
このような4つの条件のことを、まとめて「ミューテックス待機解除条件」とよぶことにする。
The policy for selecting a READY-task from a plurality of WAIT-tasks when releasing a mutex is as follows.
1. WAIT-task (first condition).
2. Among WAIT-tasks, the task must have a release mutex as a waiting mutex (second condition)
3. When there are a plurality of such tasks, the task has the highest task priority (third condition).
4). When there are a plurality of tasks having the highest task priority, the task that has entered the WAIT state is the oldest task (fourth condition).
These four conditions are collectively referred to as “mutex standby release conditions”.
したがって、ウェイトミューテックスシステムコールおよびリリースミューテックスシステムコール実行時における基本例のハードウェアRTOSの処理は以下の通りである。セマフォテーブル212には、ミューテックスIDと、そのミューテックスがいずれかのタスクに占有されているか否かを示す占有状態データが対応づけて保持されている。占有状態データは、占有されていないときには「0」であり、占有されているときにはミューテックスを占有しているタスクのタスクIDとなる。
<ウェイトミューテックスシステムコールの実行>
Therefore, the processing of the hardware RTOS in the basic example when executing the wait mutex system call and the release mutex system call is as follows. The semaphore table 212 holds a mutex ID and occupation state data indicating whether or not the mutex is occupied by any task. The occupation state data is “0” when not occupied, and becomes the task ID of the task occupying the mutex when occupied.
<Execution of wait mutex system call>
ここでは、RUN−タスクをタスクJとして説明する。
A1.タスク切換回路210は、ウェイトミューテックスシステムコールにおいて指定されたミューテックスが占有されているか検出する。以下、ミューテックスの占有状態に応じて処理は分岐する。
(ミューテックスが占有されていないとき)
A2.タスク切換回路210は、ミューテックスの占有データとして、システムコールを実行したタスクのタスクIDを記録する。
A3.タスクJのタスク状態レジスタ258に「READY」を設定する。このとき、タスク切換回路210は、RUN−タスクのタイマ252をセットしてREADY経過時間の計測を開始させる。
(ミューテックスが占有されているとき)
A2.タスク切換回路210は、タスクJのタスク状態レジスタ258に「WAIT」、待機理由レジスタ262に「ミューテックス待ち」、ミューテックスIDレジスタ265に待機ミューテックスのミューテックスIDをセットし、タイマ252をセットしてWAIT経過時間の計測を開始させる。
<リリースミューテックスシステムコールの実行>
Here, RUN-task is described as task J.
A1. The
(When the mutex is not occupied)
A2. The
A3. “READY” is set in the
(When mutex is occupied)
A2. The
<Execution of release mutex system call>
B1.タスク切換回路210は、システムコールを実行したタスクが、解放ミューテックスを占有していることを条件として、解放セマフォIDをミューテックス回路240に入力する。ミューテックス回路240も、図14と同じく多段接続された比較回路とミューテックス待機解除条件のうちの第1条件および第2条件の成否を判定する判定回路を含む。この判定回路は、このミューテックスを対象としてミューテックス待機条件のうちの第1条件および第2条件が共に成立したときだけ「1」を出力する。なお、解放ミューテックスを占有しないタスクがリリースミューテックスシステムコールを実行したときには、そのタスクの状態をRUN→READYに状態遷移させる。
(いずれかの判定回路が「1」を出力し、ミューテックス回路240からいずれかのタスクIDを出力したとき)
B2.検出されたタスクのタスク状態レジスタ258に「READY」を設定し、待機理由レジスタ262とミューテックスIDレジスタ265をクリアし、タイマ252をREADY経過時間を計測させる。
B3.システムコールを実行したタスクのタスク状態レジスタ258に「READY」に設定し、READY経過時間の計測を開始する。
(いずれの判定回路も「1」を出力せず、ミューテックス回路240がいずれのタスクIDも出力しないとき)
B2.タスク切換回路210はセマフォテーブル212において、ミューテックスを非占有状態に設定する。
B3.システムコールを実行したタスクの状態をRUN→READYに状態遷移させる。
[イベント処理]
B1. The
(When any judgment circuit outputs "1" and any task ID is output from the mutex circuit 240)
B2. “READY” is set in the
B3. The
(None of the determination circuits outputs “1” and the
B2. In the semaphore table 212, the
B3. The state of the task that executed the system call is changed from RUN to READY.
[Event processing]
基本例におけるイベント管理について簡単に説明する。イベントテーブル214には、イベントIDにフラグパターン(以下、「カレントフラグパターン」とよぶ)が対応づけて記録される。フラグパターンは8ビットのビットパターンである。
セットイベントシステムコールは、カレントフラグパターンを設定変更するシステムコールであり、イベントIDとフラグパターン(以下、「セットフラグパターン」とよぶ)をパラメータとする。セットイベントシステムコールが実行されると、該当イベントについて、カレントフラグパターンは、セットフラグパターンとの論理和に変更される。たとえば、カレントフラグパターン「00001100」、セットフラグパターン「00000101」のときには、カレントフラグパターンは、「00001101」となる。以下、各フラグパターンについて左から第0ビット、第1ビット、・・・、第7ビットとよぶ。
The event management in the basic example will be briefly described. In the event table 214, an event ID is recorded in association with a flag pattern (hereinafter referred to as “current flag pattern”). The flag pattern is an 8-bit bit pattern.
The set event system call is a system call for setting and changing the current flag pattern, and uses an event ID and a flag pattern (hereinafter referred to as “set flag pattern”) as parameters. When the set event system call is executed, the current flag pattern is changed to a logical sum with the set flag pattern for the corresponding event. For example, when the current flag pattern is “00001100” and the set flag pattern is “00000101”, the current flag pattern is “00001011”. Hereinafter, each flag pattern is referred to as 0th bit, 1st bit,..., 7th bit from the left.
ウェイトイベントシステムコールは、待機イベントのカレントフラグパターンが所定条件を満たすのを待つためのシステムコールであり、イベントID、フラグパターン(以下、「待機フラグパターン」とよぶ)、フラグ条件をパラメータとする。ウェイトイベントシステムコールが実行されると、カレントフラグパターンと待機フラグパターンの間にフラグ条件が成立するか判定される。フラグ条件は論理和(OR)または論理積(AND)である。フラグ条件が論理積(AND)の場合、待機フラグパターンにおいて「1」となっているすべてのビットについて、カレントフラグパターンの該当ビットもすべて「1」であることがWAIT解除条件となる。フラグ条件が論理和(OR)の場合、待機フラグパターンにおいて「1」となっているいずれかのビットについて、カレントフラグパターンの該当ビットが「1」であることがWAIT解除条件となる。たとえば、カレントフラグパターン「00001101」、待機フラグパターン「00000011」、フラグ条件「論理和(OR)」の場合、待機フラグパターンの第6ビットおよび第7ビットのうち、カレントフラグパターンの第7ビットが1なので、この場合には、ウェイトイベントシステムコールによるWAIT解除条件は成立する。一方、フラグ条件が「論理積(AND)」の場合、カレントフラグパターンの第6ビットが「0」なのでWAIT解除条件は成立しない。
[1]一般的なソフトウェアRTOSによるイベント処理
The wait event system call is a system call for waiting for the current flag pattern of the standby event to satisfy a predetermined condition, and uses an event ID, a flag pattern (hereinafter referred to as “standby flag pattern”), and a flag condition as parameters. . When the wait event system call is executed, it is determined whether a flag condition is satisfied between the current flag pattern and the standby flag pattern. The flag condition is logical sum (OR) or logical product (AND). When the flag condition is AND (AND), the WAIT cancellation condition is that all the corresponding bits of the current flag pattern are “1” for all the bits that are “1” in the standby flag pattern. When the flag condition is logical sum (OR), the WAIT cancellation condition is that the corresponding bit of the current flag pattern is “1” for any bit that is “1” in the standby flag pattern. For example, in the case of the current flag pattern “00001011”, the standby flag pattern “00000011”, and the flag condition “logical sum (OR)”, the seventh bit of the current flag pattern among the sixth bit and the seventh bit of the standby flag pattern is In this case, the WAIT cancellation condition by the wait event system call is satisfied. On the other hand, when the flag condition is “logical product (AND)”, since the sixth bit of the current flag pattern is “0”, the WAIT cancellation condition is not satisfied.
[1] Event processing by general software RTOS
ウェイトイベントシステムコールおよびセットイベントシステムコール実行時における一般的なRTOSの処理は以下の通りである。一般的なRTOSにおいては、イベント管理のために、メモリ上にイベントテーブルを保持する。このイベントテーブルにおいては、イベントID、カレントフラグパターンだけではなく、通常、そのイベントを待機イベントとしてWAIT状態にあるタスク(以下、「イベント待ちタスク」とよぶ)のタスクID、待機フラグパターン、フラグ条件が対応づけられて保持される。
<ウェイトイベントシステムコールの実行>
A general RTOS process at the time of executing the wait event system call and the set event system call is as follows. In general RTOS, an event table is held in a memory for event management. In this event table, not only the event ID and current flag pattern, but also the task ID, standby flag pattern, and flag condition of a task that is normally in the WAIT state with the event as a standby event (hereinafter referred to as “event waiting task”). Are associated and held.
<Execution of wait event system call>
A1.RTOSは、システムコールで指定されたイベントのカレントフラグパターンをイベントテーブルから読み出す。
A2.カレントフラグパターンと待機フラグパターンをフラグ条件にしたがって比較し、WAIT解除条件の成否を判定する。
(WAIT解除条件が成立するとき)
A3.システムコールを実行したタスクのタスク状態をRUN→READYに状態遷移させる。
(WAIT解除条件が成立しないとき)
A3.イベントテーブルに、システムコールを実行したタスクのタスクIDを記録する。
A4.イベントテーブルに待機フラグパターンを記録する。
A5.イベントテーブルにフラグ条件を記録する。
A6.システムコールを実行したタスクのタスク状態をRUN→WAITに状態遷移させる。
<セットイベントシステムコールの実行>
A1. The RTOS reads the current flag pattern of the event specified by the system call from the event table.
A2. The current flag pattern and the standby flag pattern are compared according to the flag condition to determine whether the WAIT cancellation condition is successful.
(When WAIT cancellation condition is satisfied)
A3. The task state of the task that executed the system call is changed from RUN to READY.
(When WAIT cancellation condition is not satisfied)
A3. The task ID of the task that executed the system call is recorded in the event table.
A4. Record the wait flag pattern in the event table.
A5. Record the flag condition in the event table.
A6. The task state of the task that executed the system call is changed from RUN to WAIT.
<Execution of set event system call>
B1.RTOSは、システムコールで指定された設定イベントについて、イベントテーブルからカレントフラグパターン、タスクID、待機フラグパターン、フラグ条件を読み出す。
B2.カレントフラグパターンとセットフラグパターンの論理和を新たなカレントフラグパターンとして記録する。
(設定イベントについてイベント待ちタスクが存在しないとき、または、存在したとしても待機フラグパターンとフラグ条件からWAIT解除条件が成立しないとき)
B3.システムコールを実行したタスクのタスク状態をRUN→READYに状態遷移させる。
(設定イベントについてイベント待ちタスクが存在し、WAIT解除条件が成立するとき)
B3.イベントを待機していたタスクのタスク状態をWAIT→READYに状態遷移させる。
B4.イベントテーブルにおける待機タスクID、待機フラグパターン、フラグ条件をクリアする。
B5.システムコールを実行したタスクのタスク状態をRUN→READYに状態遷移させる。また、RUN−タスクの選択が行われる。
B1. The RTOS reads the current flag pattern, task ID, standby flag pattern, and flag condition from the event table for the set event specified by the system call.
B2. The logical sum of the current flag pattern and the set flag pattern is recorded as a new current flag pattern.
(When there is no event-waiting task for the set event, or even if it exists, the WAIT cancellation condition is not satisfied from the wait flag pattern and flag condition)
B3. The task state of the task that executed the system call is changed from RUN to READY.
(When there is an event waiting task for the set event and the WAIT cancellation condition is met)
B3. The task state of the task waiting for the event is changed from WAIT to READY.
B4. The standby task ID, standby flag pattern, and flag condition in the event table are cleared.
B5. The task state of the task that executed the system call is changed from RUN to READY. In addition, a RUN-task is selected.
セットイベントシステムコールが実行されるとき、複数のWAIT−タスクの中からREADY−タスクを選択するポリシは以下の通りである。
1.WAIT−タスクであること(第1条件)。
2.WAIT−タスクのうち、設定イベントを待機イベントとするタスクであること(第2条件)。
3.待機フラグパターンとカレントフラグパターン、フラグ条件を比較してWAIT解除条件が成立するタスクであること(第3条件)
このような3つの条件のことを、まとめて「イベント待機解除条件」とよぶことにする。
[2]基本例のハードウェアRTOSによるイベント処理
When a set event system call is executed, a policy for selecting a READY-task from a plurality of WAIT-tasks is as follows.
1. WAIT-task (first condition).
2. Of the WAIT-tasks, the task must be a set event as a standby event (second condition).
3. The task must satisfy the WAIT cancellation condition by comparing the standby flag pattern, current flag pattern, and flag conditions (third condition)
These three conditions are collectively referred to as “event standby release conditions”.
[2] Event processing by hardware RTOS of basic example
タスク処理装置100のウェイトイベントシステムコールおよびセットイベントシステムコール実行時における処理は以下の通りである。タスク処理装置100が内蔵するセマフォテーブル212においては、イベントIDとカレントフラグパターンが対応づけられている。待機タスクIDや待機フラグパターンなどの情報は、状態記憶部220に格納される。
<ウェイトイベントシステムコールの実行>
Processing when the
<Execution of wait event system call>
A1.タスク切換回路210は、イベントテーブル214からカレントフラグパターンを読み出す。
A2.タスク切換回路210は、カレントフラグパターンと待機フラグパターンをフラグ条件にしたがって比較し、WAIT解除条件の成否を判定する。
(WAIT解除条件が成立するとき)
A3.システムコールを実行したタスクのタスク状態レジスタ258に「READY」を設定する。
(WAIT解除条件が成立しないとき)
A3.タスク切換回路210は、システムコールを実行したタスクのタスク状態レジスタ258に「WAIT」、待機理由レジスタ262に「イベント待ち」、イベントIDレジスタ266に待機イベントのイベントID、待機フラグレジスタ268に待機フラグパターン、フラグ条件レジスタ270にフラグ条件をそれぞれ設定する。
<セットイベントシステムコールの実行>
A1. The
A2. The
(When WAIT cancellation condition is satisfied)
A3. “READY” is set in the
(When WAIT cancellation condition is not satisfied)
A3. The
<Execution of set event system call>
B1.タスク切換回路210は、イベントテーブル214からカレントフラグパターンを読み出すとともに、システムコールで指定された設定イベントのイベントIDをイベント選択回路236に入力する。
B2.タスク切換回路210は、イベントテーブル214のカレントフラグパターンにセットフラグパターンを論理加算する。
B3.イベント選択回路236は、入力されたイベントIDについて、イベント待機条件が成立するタスクを選択する。このとき、タスク優先順位やWAIT経過時間に関わらず複数のタスクが選択されてもよい。
(イベント待機解除条件を満たすタスクが存在するとき)
B4.イベント待ちタスクのタスク状態レジスタ258に「READY」を設定し、イベントIDレジスタ266、待機フラグレジスタ268、フラグ条件レジスタ270をクリアする。
B5.システムコールを実行したタスクのタスク状態をRUN→READYに状態遷移させる。
(イベント待機解除条件を満たすタスクが存在しないとき)
B4.システムコールを実行したタスクのタスク状態をRUN→READYに状態遷移させる。
[タイムアウト処理]
B1. The
B2. The
B3. The
(When there is a task that satisfies the event waiting cancellation condition)
B4. “READY” is set in the
B5. The task state of the task that executed the system call is changed from RUN to READY.
(When there is no task that satisfies the event wait cancellation condition)
B4. The task state of the task that executed the system call is changed from RUN to READY.
[Timeout processing]
WAIT状態に移行したタスクは、WAIT解除条件が成立したときにREADY状態に遷移する。しかし、何らかの外的要因やアプリケーションプログラムのバグにより、WAIT解除条件の成立が阻害されると、タスクはWAIT状態から抜け出せなくなってしまう。そこで、通常、タスクをWAIT状態に遷移させるときにはタイムアウト値を設定する。タイムアウト値は定期的にデクリメントされ、ゼロとなったときには、WAIT解除条件が成立していなくてもタスクはWAIT状態からREADY状態に遷移する。すなわち、タイムアウト値以上の時間、タスクがWAIT状態に止まるのを防止している。
[1]一般的なソフトウェアRTOSによるタイムアウト処理
A task that has transitioned to the WAIT state transitions to the READY state when the WAIT cancellation condition is satisfied. However, if the establishment of the WAIT cancellation condition is hindered due to some external factor or a bug in the application program, the task cannot escape from the WAIT state. Therefore, normally, a timeout value is set when the task is shifted to the WAIT state. The timeout value is decremented periodically, and when it becomes zero, the task transitions from the WAIT state to the READY state even if the WAIT cancellation condition is not satisfied. That is, the task is prevented from stopping in the WAIT state for a time longer than the timeout value.
[1] Time-out processing by general software RTOS
ソフトウェアによる一般的なRTOSの場合、WAIT状態のタスクのTCBにはタイムアウト値が設定され、このタイムアウト値は定期的にデクリメントされる。RTOSは周期的にCPUの処理に割り込みをかけ、全TCBをチェックし、タイムアウト値がゼロに至ったWAIT−タスクを検出する。このようなタスクが検出されたときには、RTOSはそのタスクのタスク状態をWAITからREADYに状態遷移させる。
[2]基本例のハードウェアRTOSによるタイムアウト処理
In the case of a general RTOS by software, a timeout value is set in the TCB of a task in a WAIT state, and this timeout value is periodically decremented. The RTOS periodically interrupts the processing of the CPU, checks all TCBs, and detects a WAIT-task whose timeout value has reached zero. When such a task is detected, the RTOS changes the task state of the task from WAIT to READY.
[2] Time-out process by hardware RTOS of basic example
一方、基本例の場合、タスク切換回路210は各タイムアウトカウンタ274のタイムアウト値を定期的にデクリメントする。タイムアウト値は、WAIT系システムコールを実行する時にパラメータとして設定され、タスク切換回路210はそのシステムコールを実行したタスクのタイムアウトカウンタ274にタイムアウト値を設定する。
On the other hand, in the basic example, the
タイムアウト値のデクリメント処理にCPU150が介在しないため、タスク切換回路210がタスク実行処理とは独立してタイムアウト値を更新できる。そのため、CPU150がタスクを実行している最中にも、タスク制御回路200において自律的にタイムアウト値の更新がなされる。タイムアウト検出回路238には状態データが常時入力されているので、タイムアウト検出回路238は、タイムアウトカウント値が更新されたタイミングとほぼ同じタイミングにて、タイムアウトカウント値がゼロとなったタスクを検出できる。タイムアウト検出回路238は、そのようなタスクのタスクIDを出力する。タスク切換回路210は、タイムアウト検出回路238からタスクIDを入力されると、タイムアウトが発生したと認識し、HCをアサートしてCPUクロックを供給停止させる。タスク制御回路200は、タイムアウトが発生したWAIT−タスクをREADY状態に遷移させるとともに、RUN−タスクをREADY状態に遷移させる。タスク切換回路210は、READY−タスクの中から次に実行すべきタスクを選択する。また、タスク切換回路210は、タイムアウトが発生したタスクのタイマ252をリスタートさせ、READY経過時間を計測させる。
Since the
このような処理方法によれば、タスクの実行中、すなわち、CPUクロックの動作中にタイムアウトが発生したときに、即時的にCPU150に割り込みをかけて、タスクスイッチを実行できる。また、タスクの実行中において、タスク切換回路210はCPU150の処理能力を借りることなく独立してタイムアウト値の更新処理を実行できる。
[有限ステートマシンとしてのタスク切換回路210]
According to such a processing method, when a timeout occurs during execution of a task, that is, during operation of the CPU clock, it is possible to immediately interrupt the
[
図15は、タスク切換回路210の状態遷移図である。
初期化処理(A1)においては、全タスクがIDLE状態にある。初期化処理が完了すると(S10)、いずれかのタスクがRUN−タスクとなりタスク実行状態(A2)となる。割り込み要求信号が検出されると(S12)、特殊タスクがRUN−タスクとなり、割り込み処理(A3)が実行される。割り込み処理が終了すると(S14)、タスク切換回路210は、一般タスクからRUN−タスクを選択し、A2に遷移する。
FIG. 15 is a state transition diagram of the
In the initialization process (A1), all tasks are in the IDLE state. When the initialization process is completed (S10), one of the tasks becomes a RUN-task and enters the task execution state (A2). When an interrupt request signal is detected (S12), the special task becomes a RUN-task, and interrupt processing (A3) is executed. When the interrupt process ends (S14), the
また、タスク実行中(A2)において、システムコールが実行されると(S16)、システムコール処理が実行される(A4)。タスクスイッチ、すなわち、RUN−タスクの切り換えが発生しない場合には(S18)、A2に戻る。一方、システムコール処理(A4)により、タスクスイッチが発生する場合には(S20)、タスク切換回路210は実行選択回路232の出力に基づいてRUN−タスクの選択を行う(A5)。タスクスイッチが完了すると(S22)、処理状態はA2に移行する。
基本例に関連して、更に、タスク処理装置100の主要素である退避回路120とタスク制御回路200のうち一方のみを実装する場合について付言する。
[タスク制御回路200を搭載しないタイプのタスク処理装置100]
When a system call is executed during task execution (A2) (S16), system call processing is executed (A4). If task switching, that is, RUN-task switching does not occur (S18), the process returns to A2. On the other hand, when a task switch occurs due to the system call process (A4) (S20), the
In relation to the basic example, a case where only one of the
[A
図16は、図5のタスク処理装置100のうち、タスク制御回路200を搭載しないタスク処理装置100の回路図である。
タスク制御回路200を搭載しない代わりに、レジスタ切換制御回路322と処理データ保持部320を追加している。タスク制御回路200を搭載しないため、タスクスケジューリング機能はソフトウェアRTOSにより実現される。したがって、RTOSはタスクスイッチに際して、CPU150の使用権を一時的に取得する必要が生じる。処理データ保持部320は、通常、RTOSのための処理データを保持する。RTOSがCPU150の使用権を取得するときには、処理データ保持部320は処理データ保持部320にあるRTOS用の処理データと特殊レジスタ156のタスク用の処理データを入れ替える。以下、タスクAからタスクBへタスクスイッチするとして、その処理過程を説明する。
FIG. 16 is a circuit diagram of the
Instead of mounting the
A1.タスクAがシステムコール実行するとき、システムコールの変数やシステムコールのIDを汎用レジスタ158の一部に記録する。
A2.レジスタ切換制御回路322は、タスクAの処理データを処理データ保持部320に移動させ、処理データ保持部320のRTOS用処理データを処理レジスタ154にロードする。この段階で、RTOSがCPU150の使用権を取得する。
A3.レジスタ切換制御回路322は、退避レジスタ110aに書き込み信号を入力し、処理データ保持部320のタスクA用処理データを退避レジスタ110に退避させる。
A4.RTOSは、汎用レジスタ158に記録されているシステムコールの変数やIDに基づき、システムコールに対応する処理を実行する。また、タスクAのTCBのタスク状態データを「READY」に設定し、タスクレディリストにタスクAのTCBを追加する。
A1. When the task A executes a system call, the system call variable and the system call ID are recorded in a part of the general-
A2. The register
A3. The register
A4. The RTOS executes processing corresponding to the system call based on the system call variable and ID recorded in the general-
B1.次に、RTOSは先述したRUNタスク選択条件にしたがって、RUN−タスク、ここでは、タスクBを選択する。
B2.RTOSはレジスタ切換制御回路322に指示して、タスクBを指定したタスク選択信号をロード選択回路112に入力させる。退避レジスタ110bから処理データ保持部320に処理データが移動される。
B3.レジスタ切換制御回路322は、処理データ保持部320のタスクB用処理データと処理レジスタ154のRTOS用処理データを入れ替える。これにより、タスクBがCPU150の使用権を取得する。
B1. Next, the RTOS selects a RUN-task, in this case, task B, according to the RUN task selection condition described above.
B2. The RTOS instructs the register
B3. The register
このような処理方法によれば、タスク制御回路200を搭載する図5のタスク処理装置100に比べて、タスク処理装置100全体としての回路サイズをコンパクトにできる。RTOSはソフトウェアとして実現されるが、処理データのロード・退避はレジスタ切換制御回路322からの信号によってハードウェア制御できる。処理レジスタ154、処理データ保持部320、ロード選択回路112、退避レジスタ110をそれぞれつなぐバスは処理データをパラレル転送可能なビット数に設定すれば、TCBへの処理データの退避やTCBからの処理データのロードに比べて高速なタスクスイッチが可能となる。
[退避回路120を搭載しないタイプのタスク処理装置100]
According to such a processing method, the circuit size of the
[A
図17は、図5のタスク処理装置100のうち、退避回路120を搭載しないタスク処理装置100の回路図である。
退避回路120を搭載しない代わりに、割込インタフェース回路324を追加している。退避回路120を搭載しないため、処理データはメモリのTCBに退避される。処理データの退避・ロードに関してはソフトウェアベースのRTOSにより実現される。したがって、RTOSはタスクスイッチに際して、CPU150の使用権を一時的に取得する必要が生じる。以下、タスクAからタスクBへタスクスイッチするとして、その処理過程を説明する。
FIG. 17 is a circuit diagram of the
Instead of mounting the
システムコールの実行によりタスクスイッチが発生すると、まず、ソフトウェアRTOSがタスクAの処理データをタスクAのTCBに退避させる。そして、RTOS用の処理データを処理レジスタ154にロードする。このときの処理方法は、図3に関連して説明した内容と同等となる。
When a task switch occurs due to the execution of a system call, first, the software RTOS saves the processing data of task A in the TCB of task A. Then, the processing data for RTOS is loaded into the
ソフトウェアRTOSは、割込インタフェース回路324にシステムコールのパラメータを書き込む。実行制御回路152は、CPU150のCPUクロックを停止させる。割込インタフェース回路324は、タスク制御回路200にタスクスイッチを実行させる。タスク切換回路210は、まず、タスクAのタスク状態レジスタ258をREADYに設定し、タスク選択回路230からの出力により次のRUN−タスクであるタスクBを選択する。タスク切換回路210は、割込インタフェース回路324に指示してタスクBの処理データをロードを指示する。ここで、割込インタフェース回路324は実行制御回路152にCPUクロックを再開させる。また、割込インタフェース回路324は、タスクBが選択された旨をソフトウェアRTOSに通知する。ソフトウェアRTOSは、タスクBのTCBにアクセスし、タスクBの処理データを処理レジスタ154にロードする。
The software RTOS writes the system call parameters in the interrupt
このような処理方法によっても、退避回路120を搭載する図5のタスク処理装置100に比べて、タスク処理装置100全体としての回路サイズをコンパクトにできる。RTOSの機能の一部はソフトウェアとして実現されるが、タスク選択処理はタスク制御回路200により実現できる。
Even with such a processing method, the circuit size of the
図2および図3に関連して説明したソフトウェアRTOSに比べて、図16および図17のタスク処理装置100は、いずれもRTOSの機能の一部をハードウェア化することができる。図16に関連して説明したように、退避回路120が存在することによって、処理データの退避・ロードのためにTCBにアクセスする必要がなくなる。このため、レジスタ切換制御回路322により処理データの退避・ロード処理を実行可能となっている。また、図17に関連して説明したように、タスク制御回路200が存在することによって、ソフトウェアRTOSはタスク選択機能をタスク制御回路200に委譲できる。
Compared to the software RTOS described with reference to FIGS. 2 and 3, the
図5に関連して説明したように、退避回路120とタスク制御回路200を搭載するタスク処理装置100の場合、RTOSのタスクスケジューリング機能を完全にハードウェア化できる。タスクスイッチに際してメモリのTCBにアクセスする必要性がなくなるため、タスクスイッチ処理がいっそう高速化される。本発明者らの実験によると、図3等に関連して説明した一般的なソフトウェアRTOSに比べて、基本例におけるタスク処理装置100は約100倍の速度で動作することが確認されている。
{仮想キュー実装例(SPシステム)}
As described with reference to FIG. 5, in the case of the
{Virtual queue implementation example (SP system)}
次に、仮想キュー実装例として、両投入型のキューアルゴリズムをハードウェア実装するタスク処理装置100について説明する。基本例のタスク処理装置100は、タイマ管理に基づくタスクスケジューリング機能を搭載している。基本例のタスクスケジューリングは、「タスク優先順位が同じである限り、待ち時間が長いタスクに優先的に実行権を割り当てる」アルゴリズムである。以下、このようなタスクスケジューリングを「公平型タスクスケジューリング」とよぶ。
Next, as a virtual queue implementation example, a
図11においても公平型タスクスケジューリングの考え方に基づいてタスクレディリストの管理方法を説明した。RUN−タスクであるタスクJがREADY状態に戻るときには、最後尾のタスクFの後ろに連結される。タスクJの次には、タスクAがRUN−タスクとなるので、タスク優先順位「0」の優先順位ポインタ280には、タスクD、・・・、タスクF、タスクJという順に各タスクのTCBが連結されることになる。タスクJは、少なくとも、タスクFの実行が終わるまで実行権を与えられない。公平型タスクスケジューリングにおける処理方法は、FIFO、すなわち、キューのアルゴリズムに似ている。時間管理に馴染みやすいアルゴリズムであるため、タイマ管理により公平型タスクスケジューリングをハードウェア実装できる。
In FIG. 11 as well, the task ready list management method has been described based on the concept of fair task scheduling. When task J, which is a RUN-task, returns to the READY state, it is linked after the last task F. Since task A becomes a RUN-task next to task J, the TCB of each task is displayed in the order of task D,..., Task F, task J in the
一方、ソフトウェアOSにおいては、「タスク優先順位が同じである限り、いったんRUN−タスクとなったタスクには優先的に実行権を割り当てる」というタスクスケジューリングが採用されることも多い。以下、このようなタスクスケジューリングを「再実行優先型タスクスケジューリング」とよぶ。再実行優先型タスクスケジューリングでは、RUN−タスクであるタスクJがREADY状態に戻るときには、最後尾ではなく先頭に挿入される。タスクJの次には、タスクAがRUN−タスクとなるので、タスク優先順位「0」の優先順位ポインタ280には、タスクJ、タスクD、・・・、タスクFという順に各タスクのTCBが連結されることになる。タスクJは、タスクAが終了すると、タスクDやタスクFよりも先に実行権を再付与される。いったん実行権を与えられたら、なるべくまとめて実行させたいタイプのタスクが存在するときには、再実行優先型タスクスケジューリングは有効である。再実行優先型タスクスケジューリングは、LIFO、すなわち、スタック的なアルゴリズムを含んでいるといえる。仮想キュー実装例では、FIFOを基本としつつもLIFOにも対応できる両投入型キューアルゴリズムのハードウェア実装により、再実行優先型タスクスケジューリングを実現する。
なお、再実行優先型タスクスケジューリングに限らず、両投入型キューアルゴリズムは一般的なアプリケーションプログラムにおいても有用である。このため、両投入型キューアルゴリズムのハードウェア実装は、さまざまなコンピュータプログラムの処理速度を向上させる上で有効である。
On the other hand, in the software OS, task scheduling of “assigning an execution right preferentially to a task once a RUN-task as long as the task priority is the same” is often adopted. Hereinafter, such task scheduling is referred to as “re-execution priority type task scheduling”. In the re-execution priority type task scheduling, when the task J, which is a RUN-task, returns to the READY state, it is inserted at the head instead of the tail. Since task A becomes a RUN-task next to task J, the TCB of each task is displayed in the order of task J, task D,... Will be linked. When the task A is completed, the task J is reassigned the execution right before the task D and the task F. Once the execution right is given, the re-execution priority type task scheduling is effective when there are types of tasks that should be executed together as much as possible. It can be said that the re-execution priority type task scheduling includes a LIFO, that is, a stack-like algorithm. In the virtual queue implementation example, the re-execution priority type task scheduling is realized by the hardware implementation of the double-throw type queue algorithm that is compatible with LIFO while being based on FIFO.
Note that not only the re-execution priority type task scheduling but also the double-input type queue algorithm is useful in general application programs. For this reason, the hardware implementation of the double-throw queue algorithm is effective in improving the processing speed of various computer programs.
図18は、仮想キュー実装例におけるタスク処理装置100の回路図である。
仮想キュー実装例におけるタスク処理装置100も、CPU150に加えて退避回路120とタスク制御回路200を含む。ただし、仮想キュー実装例におけるタスク切換回路210は、メイン回路400、書込回路402、キュー制御回路404および最大値選択回路406を含む。メイン回路400は、基本例におけるタスク切換回路210とほぼ同等の機能を備える回路である。このため、仮想キュー実装例におけるタスク切換回路210は、基本例におけるタスク切換回路210としてのメイン回路400に書込回路402、キュー制御回路404および最大値選択回路406を追加した構成となっている。各状態記憶部220からは全タスクの全状態データが、タスク選択回路230だけではなく、最大値選択回路406やキュー制御回路404にも常時出力されている。
FIG. 18 is a circuit diagram of the
The
図19は、仮想キュー実装例におけるタスク制御回路200の部分的な回路図である。
タスク制御回路200の基本構成は、図10に示した回路構成とほぼ同等である。各タスクに対応づけられる状態レジスタ250は、タスクIDレジスタ410、タスク優先順位レジス412、キュー順序レジスタ414、キュー識別レジスタ416を含む。状態レジスタ250は、そのほかのレジスタを含んでもよいが、ここでは両投入型キューアルゴリズムに関わるレジスタ群を中心として説明する。
(A)タスクIDレジスタ410:タスクIDを保持する。基本例に示したタスクIDレジスタ254と同等である。タスクIDレジスタ410からはタスクIDを示すEID_S信号が常時出力される。
(B)タスク優先順位レジスタ412:タスク優先順位(PR)を保持する。基本例に示したタスク優先順位レジスタ256と同様である。PR_S信号として常時出力される。
(C)キュー順序レジスタ414:後述する仮想キューへの投入順位を示す「順序値(ODR)」を保持する。順序値が大きいほど、仮想キューの深くに投入されていることを示すが、詳しくは後述する。順序値は、ODR_S信号として常時出力される。
(D)キュー識別レジスタ416:仮想キューを識別する「キューID(QID)」を保持する。QID_S信号として常時出力される。
タスク優先順位レジスタ412と、キュー順序レジスタ414、キュー識別レジスタ416は、特に、仮想キューを管理するためのキューレジスタとして機能する。
FIG. 19 is a partial circuit diagram of the
The basic configuration of the
(A) Task ID register 410: Holds a task ID. This is equivalent to the task ID register 254 shown in the basic example. The
(B) Task priority order register 412: Holds task priority order (PR). This is the same as the task priority order register 256 shown in the basic example. Always output as a PR_S signal.
(C) Queue order register 414: Holds an “order value (ODR)” indicating the order of entry into a virtual queue to be described later. The larger the order value, the deeper the virtual queue is, which will be described later in detail. The order value is always output as an ODR_S signal.
(D) Queue identification register 416: Holds a “queue ID (QID)” for identifying a virtual queue. Always output as the QID_S signal.
The task
仮想キューは、タスク状態に対応づけられるキューである。たとえば、QID=0の仮想キュー(以下、「仮想キュー(0)」のように表記する)をREADY状態、仮想キュー(1)をセマフォ待ち状態、仮想キュー(2)をミューテックス待ち状態に対応づけてもよい。あるいは、仮想キュー(1)をセマフォID=0についてのセマフォ待ち状態、仮想キュー(2)をセマフォID=1についてのセマフォ待ち状態に対応づけてもよい。QIDとタスク状態の対応づけは、ソフトウェアにて任意に設定すればよい。 A virtual queue is a queue associated with a task state. For example, the virtual queue with QID = 0 (hereinafter referred to as “virtual queue (0)”) is associated with the READY state, the virtual queue (1) is associated with the semaphore wait state, and the virtual queue (2) is associated with the mutex wait state. May be. Alternatively, the virtual queue (1) may be associated with the semaphore waiting state for semaphore ID = 0, and the virtual queue (2) may be associated with the semaphore waiting state for semaphore ID = 1. The association between the QID and the task state may be arbitrarily set by software.
タスクAがREADY状態であるとき、キュー識別レジスタ416_Aには、READY状態に対応づけられる仮想キューのQIDが設定される。タスク選択回路230やキュー制御回路404は、各キュー識別レジスタ416を参照することにより、各タスクのタスク状態を判別できる。このため、キュー識別レジスタ416は、基本例におけるタスク状態レジスタ258、待機理由レジスタ262、セマフォIDレジスタ264、ミューテックスIDレジスタ265、イベントIDレジスタ266等と同等に機能できる。
When the task A is in the READY state, the QID of the virtual queue associated with the READY state is set in the queue identification register 416_A. The
仮想キューは、物理的に存在するものではなく、キュー順序レジスタ414やキュー識別レジスタ416の設定内容によって想定される概念的なキューである点は重要である。たとえば、各キュー識別レジスタ416とキュー順序レジスタ414において、
タスクA:QID=0、ODR=0
タスクB:QID=0、ODR=1
タスクC:QID=0、ODR=2
タスクD:QID=1、ODR=0
として設定されているときには、仮想キュー(0)には、タスクC、B、Aの順に投入されており、仮想キュー(1)には、タスクDだけが投入されていることを示す。QIDとODRの数値範囲によって仮想キューの数やサイズを柔軟に変更できる。
It is important that the virtual queue does not physically exist but is a conceptual queue assumed by the setting contents of the
Task A: QID = 0, ODR = 0
Task B: QID = 0, ODR = 1
Task C: QID = 0, ODR = 2
Task D: QID = 1, ODR = 0
Is set in the virtual queue (0) in the order of tasks C, B, and A, and only the task D is input in the virtual queue (1). The number and size of virtual queues can be flexibly changed according to the numerical range of QID and ODR.
タスク選択回路230は、状態レジスタ250から出力される状態データに基づいて、状態遷移させるべきタスクを選択する。メイン回路400は、CND信号をタスク選択回路230に入力する。CNDはタスク選択条件を示す信号であり、キューIDを示すQID_Cとタスク優先順位を示すPR_Cを含む。たとえば、仮想キュー(0)からタスクを抽出したい場合、メイン回路400は、CNDにQID_C=0を設定する。タスク選択回路230は、指定された仮想キュー(0)において抽出対象となるタスク(以下、単に「抽出タスク」とよぶ)のタスクIDをEID_A1に出力し、EID_A1_ENをアサートする。また、PR_A1、ODR_A1には、抽出タスクのタスク優先順位と順序値が出力される。このように、メイン回路400は、QID_C=Qnを指定してタスク選択回路230に問い合わせることにより、仮想キュー(Qn)の抽出タスクを知ることができる。タスク選択回路230は抽出タスクを選択する抽出候補回路として機能する。より詳細については図32に関連して後述する。
The
最大値選択回路406には、メイン回路400からCND信号が入力される。最大値選択回路406は、CNDによりQID_C=Qnが指定されると、仮想キュー(Qn)における最大順序値をODR_A2に出力し、EID_A2_ENをアサートする。より詳細については図28に関連して後述する。
The maximum
キュー制御回路404は、各状態レジスタ250の状態データを設定することにより、各タスクの状態遷移を制御する。キュー制御回路404には、メイン回路400からCMDとEID_Cを入力される、そのほかにも、CND(QID_C、PR_C)、ODR_A1、ODR_A2、ODR_A2_ENと各状態レジスタ250の状態データが入力される。
The
CMDは、仮想キューを操作するためのコマンドを示す。CMDの対象となる仮想キューのキューID、タスクのタスクID、タスク優先順位は、それぞれ、QID_C、EID_C、PR_Cにより指定される。コマンドは、ENQ_TL、ENQ_TP、DEQの3種類のうちのいずれかである。 CMD indicates a command for operating the virtual queue. The queue ID of the virtual queue subject to CMD, the task ID of the task, and the task priority are designated by QID_C, EID_C, and PR_C, respectively. The command is one of three types of ENQ_TL, ENQ_TP, and DEQ.
順投入コマンドENQ_TLが入力されると、仮想キューの最後尾からEID_C信号により指定されたタスクが投入される。以下、キューの最後尾からの投入を「順投入」とよぶ。抽出コマンドDEQが入力されると、仮想キューの先頭からタスクが取り出される。ENQ_TLとDEQにより、FIFOとしてのキュー制御が実行される。逆投入コマンドENQ_TPが入力されると、仮想キューの先頭からEID_C信号により指定されたタスクが投入される。以下、このようなキューの先頭からの投入を「逆投入」とよぶ。逆投入は、FIFOとしての投入ではない点で特殊な投入方法である。 When the sequential input command ENQ_TL is input, the task specified by the EID_C signal is input from the tail of the virtual queue. Hereinafter, input from the tail of the queue is referred to as “ordered input”. When the extraction command DEQ is input, a task is taken out from the head of the virtual queue. The queue control as a FIFO is executed by ENQ_TL and DEQ. When the reverse input command ENQ_TP is input, the task specified by the EID_C signal is input from the head of the virtual queue. Hereinafter, the input from the head of such a queue is referred to as “reverse input”. Reverse injection is a special input method in that it is not input as a FIFO.
メイン回路400からCMDが入力されると、書込回路402はWTをアサートし、キュー制御回路404から出力される各データの状態レジスタ250への書き込みが実行される。キュー制御回路404や書込回路402、タスク選択回路230、最大値選択回路406等が、仮想キューを制御するための仮想キュー処理回路として機能する。
キュー制御回路404の回路構成については、次の図20に関連して詳述する。
When CMD is input from the
The circuit configuration of the
図20は、キュー制御回路404の回路図である。
キュー制御回路404は、複数のレジスタ値生成回路420の集合体である。各レジスタ値生成回路420は同じ回路である。レジスタ値生成回路420は、タスクごとに対応づけられている。状態レジスタ250ごとに対応づけられているともいえる。レジスタ値生成回路420_Enは、タスクID=Enのタスク(以下、「タスク(En)」のように表記する)に対応づけられる。レジスタ値生成回路420には、該当タスクのタスクIDがELM_ID信号として固定的に入力される。
FIG. 20 is a circuit diagram of the
The
ODR_S、QID_S、PR_Sは、状態レジスタ250から出力される状態データであり、それぞれ、順序値、キューID、タスク優先順位を示す。タスク(En)に対応づけられるレジスタ値生成回路420_Enには、タスク(En)の順序値、キューID、タスク優先順位がそれぞれODR_S_En、QID_S_En、PR_S_Enとして入力される。CMD、EID_Cは、メイン回路400から入力される。ODR_A2_ENとODR_A2は、最大値選択回路406から入力される。最大順序値を示すODR_A2は、ODR_A2_ENがアサートされるときに有効な入力となる。ODR_A1は、タスク選択回路230から入力される。ODR_A1は、抽出タスクのタスクIDを示す。QID_CとPR_Cは、メイン回路400から入力されるCND信号であり、それぞれ、タスク選択条件としてのQIDとPRを示す。
レジスタ値生成回路420_Enは、タスク(En)の順序値、キューID、タスク優先順位をそれぞれQID_N_En、ODR_N_En、PR_N_Enとして出力し、書込回路402によりWTがアサートされたときに状態レジスタ250_Enに書き込まれる。
書込回路402がWTをアサートすると、全てのレジスタ値生成回路420のQID_N_En、ODR_N_En、PR_N_Enが全ての状態レジスタ250に書き込まれる。CMDにより影響を受けるタスクについてのレジスタ値生成回路420は、後述するアルゴリズムにて指定される新たなデータを状態レジスタ250に書き込む。一方、CMDにより影響を受けないタスクについてのレジスタ値生成回路420も、状態レジスタ250に書き込まれているデータと同じデータを再出力して書き込みを実行する。
なお、レジスタ値生成回路420のWTは、各状態レジスタ250ではなくキュー制御回路404に直接入力されてもよい。この場合、キュー制御回路404に内蔵されるレジスタ値生成回路420のうち、CMDにより状態変更すべきタスクについてのレジスタ値生成回路420だけが、新たなデータを状態レジスタ250に書き込むとしてもよい。
レジスタ値生成回路420の具体的な処理内容については後述する。
ODR_S, QID_S, and PR_S are status data output from the
The register value generation circuit 420_En outputs the task (En) order value, queue ID, and task priority as QID_N_En, ODR_N_En, and PR_N_En, respectively, and is written in the state register 250_En when the
When the
Note that the WT of the register value generation circuit 420 may be directly input to the
Specific processing contents of the register value generation circuit 420 will be described later.
図21は、仮想キューとタスクの関係を示す概念図である。
ここでは、仮想キュー(Q0)と仮想キュー(Q1)の2つの仮想キューを想定している。仮想キュー(Q0)は、タスク優先順位PR=0のタスクが投入される優先キュー(以下、「優先キュー(Q0:0)」と表記する)とタスク優先順位PR=1のタスクが投入される優先キュー(Q0:1)の2つの優先キューの集合である。仮想キュー(Q1)についても同様であり、実質的には4つの優先キューが想定される。たとえば、仮想キュー(Q0)はREADY状態、仮想キュー(Q1)はWAIT状態に対応づけられてもよい。
FIG. 21 is a conceptual diagram showing the relationship between virtual queues and tasks.
Here, two virtual queues of a virtual queue (Q0) and a virtual queue (Q1) are assumed. In the virtual queue (Q0), a priority queue (hereinafter referred to as “priority queue (Q0: 0)”) into which tasks with task priority PR = 0 are input and a task with task priority PR = 1 are input. This is a set of two priority queues of priority queues (Q0: 1). The same applies to the virtual queue (Q1), and substantially four priority queues are assumed. For example, the virtual queue (Q0) may be associated with the READY state, and the virtual queue (Q1) may be associated with the WAIT state.
各仮想キューは、同図向かって左を投入口、右を抽出口とするキューである。順投入においては左側からタスクが投入され、逆投入においては右側からタスクが投入される。タスクが抽出されるのは常に右側からである。 Each virtual cue is a cue having an input port on the left and an extraction port on the right as viewed in FIG. Tasks are entered from the left side in the forward entry, and tasks are entered from the right side in the reverse entry. Tasks are always extracted from the right side.
同図では、タスクID=E0、E1、E2、E3の4つのタスクが仮想キューに投入されている。タスク(E0)とタスク(E2)、タスク(E3)は仮想キュー(Q0)に投入されている。このうち、タスク(E0)とタスク(E3)は、タスク優先順位PR=0のタスクであるため、優先キュー(Q0:0)に投入される。タスク(E2)はPR=1のタスクであるため、優先キュー(Q0:1)に投入される。仮想キュー(Q0)に投入されるタスク(E3)、タスク(E2)、タスク(E0)の順序値ODRは、2、1、0となっている。タスク優先順位PR=0のタスク(E1)は、仮想キュー(Q1)に投入されている。ODRは「0」である。 In the figure, four tasks with task ID = E0, E1, E2, E3 are put in the virtual queue. The task (E0), the task (E2), and the task (E3) are put in the virtual queue (Q0). Among these, the task (E0) and the task (E3) are tasks with the task priority order PR = 0, and are therefore placed in the priority queue (Q0: 0). Since the task (E2) is a task with PR = 1, it is put into the priority queue (Q0: 1). The order values ODR of the task (E3), the task (E2), and the task (E0) input to the virtual queue (Q0) are 2, 1, 0. The task (E1) having the task priority order PR = 0 is put in the virtual queue (Q1). The ODR is “0”.
図22は、図21に対応した状態レジスタ250のデータ構造図である。
図21に示した仮想キューへの各タスクの投入状態は、状態レジスタ250の設定により表現される。図21に示した状態においては、タスク(E0)〜タスク(E7)のうち、仮想キューに投入されているのはタスク(E0)〜タスク(E3)である。このため、それ以外のタスクのキュー識別レジスタ416には未投入を示す「Non」が設定される。仮想キュー(Q0)に投入されるタスク(E0)、タスク(E3)、タスク(E2)のキュー識別レジスタ416には「Q0」が設定される。また、仮想キュー(1)に投入されるタスク(E1)のキュー識別レジスタ416には「Q1」が設定される。キュー識別レジスタ416の設定内容により、どのタスクがどの仮想キューに投入されているかを表現する。
FIG. 22 is a data structure diagram of the
The input status of each task to the virtual queue shown in FIG. 21 is expressed by the setting of the
仮想キュー(Q0)に投入されている3つのタスク(E0)、タスク(E3)、タスク(E2)のキュー順序レジスタ414には、それぞれODRとして0、2、1が設定される。仮想キュー(Q1)に投入されているタスクは、タスク(E1)だけなので、順序値は最小の「0」が設定される。キュー順序レジスタ414の設定内容により、各タスクの仮想キューにおける位置を表現する。
In the queue order registers 414 of the three tasks (E0), task (E3), and task (E2) put in the virtual queue (Q0), 0, 2, and 1 are set as ODR, respectively. Since only the task (E1) is put in the virtual queue (Q1), the minimum order value is set to “0”. The position of each task in the virtual queue is expressed by the setting contents of the
タスク(E0)、タスク(E1)、タスク(E3)のタスク優先順位PRは「0」である。そこで、これらのタスクのタスク優先順位レジスタ412には「0」が設定される。タスク(E2)のタスク優先順位PRは「1」であるため、タスク優先順位レジスタ412_E2には「1」が設定される。タスク優先順位レジスタ412の設定により、各タスクがどの優先キューに投入されているかを表現する。
以上の設定に基づいて、順投入、逆投入、抽出における処理内容について詳述する。
[順投入]
The task priority order PR of task (E0), task (E1), and task (E3) is “0”. Therefore, “0” is set in the task priority order register 412 of these tasks. Since the task priority order PR of the task (E2) is “1”, “1” is set in the task priority order register 412_E2. According to the setting of the task
Based on the above settings, the processing contents in the forward input, reverse input, and extraction will be described in detail.
[Sequential input]
図23は、図21の仮想キューにタスク(E4)を順投入するときの概念図である。
ここでは、仮想キュー(Q1)にタスク優先順位PR=0のタスク(E4)を順投入するとして説明する。メイン回路400は、CMD=ENQ_TL(順投入コマンド)として、EID_C=E4、QID_C=Q1、PR_C=0を設定する。キュー制御回路404に内蔵されるレジスタ値生成回路420_E4は、EID_C=ELM_ID=E4を検出すると、QID_N_E4=QID_C=Q1、ODR_N_E4=0、PR_N_E4=PR_C=0を出力する。QID_N_E4はタスク(E4)の投入先となる仮想キューのQID、ODR_N_E4は投入時における順序値、PR_N_E4はタスク(E4)のタスク優先順位である。順投入されるタスクについてのODR_Nは、常に「0」に設定される。これは、キューに対する最新の投入を示す順序値である。
FIG. 23 is a conceptual diagram when tasks (E4) are sequentially entered into the virtual queue of FIG.
Here, description will be made assuming that the task (E4) with the task priority order PR = 0 is sequentially placed in the virtual queue (Q1). The
レジスタ値生成回路420_E4だけでなく、QID_S_En=QID_C=Q1となるレジスタ値生成回路420_Enも反応する。レジスタ値生成回路420_Enは、ODR_N_En=ODR_S_En+1を出力する。ここでは、レジスタ値生成回路420_E1がQID_S_E1=QID_C=Q1を検出し、ODR_N_E1=0+1=1を出力する。ODR_N_E1はタスク(E1)投入後の順序値である。タスク(E4)の順投入先となる仮想キュー(Q1)に既に投入されているタスクは、順序値が影響を受けることになる。このような処理過程を経て、仮想キュー(Q1)の要素であるタスク(E4)とタスク(E1)の状態データが調整される。
Not only the register value generation circuit 420_E4 but also the register value generation circuit 420_En in which QID_S_En = QID_C = Q1 reacts. The register value generation circuit 420_En outputs ODR_N_En =
図24は、図23に対応した状態レジスタ250のデータ構造図である。
同図において下線を付与している部分が、図22に示した状態レジスタ250の設定内容から変化した箇所である。タスク(E4)の仮想キュー(Q1)への順投入により、キュー識別レジスタ416_E4にはQID_N_E4により「Q1」が設定される。タスク(E4)のODRは「0」、PRは「0」である。タスク(E4)の順投入により、仮想キュー(Q1)に既に投入されていたタスク(E1)のODRは、「0」から「1」にインクリメントされる。変更後の状態レジスタ250の設定内容により、図23に示した仮想キュー(Q1)の状態が表現される。
FIG. 24 is a data structure diagram of the
In FIG. 22, the underlined portion is a portion changed from the setting contents of the
図25は、図23の仮想キューにタスク(E5)を順投入するときの概念図である。
ここでは、仮想キュー(Q0)にタスク優先順位PR=1のタスク(E5)を順投入するとして説明する。メイン回路400は、CMD=ENQ_TL(順投入コマンド)として、EID_C=E5、QID_C=Q0、PR_C=1を設定する。レジスタ値生成回路420_E5は、QID_N_E5=QID_C=Q0、ODR_N_E5=0、PR_N_E5=PR_C=1を出力する。
FIG. 25 is a conceptual diagram when the tasks (E5) are sequentially entered into the virtual queue of FIG.
Here, a description will be given assuming that the task (E5) with the task priority order PR = 1 is sequentially entered into the virtual queue (Q0). The
レジスタ値生成回路420_E5だけでなく、QID_C=QID_S_En=Q0となるレジスタ値生成回路420_Enは、QID_C=QID_S_Enを検出すると、ODR_N_En=ODR_S_En+1を出力する。この例では、タスク(E0)、タスク(E2)、タスク(E3)に対応するレジスタ値生成回路420が該当する。こうして、仮想キュー(Q0)の要素であるタスク(E5)とタスク(E0)、タスク(E2)、タスク(E3)の状態データが調整される。 Not only the register value generating circuit 420_E5 but also the register value generating circuit 420_En that satisfies QID_C = QID_S_En = Q0 outputs ODR_N_En = ODR_S_En + 1 when detecting QID_C = QID_S_En. In this example, the register value generation circuit 420 corresponding to the task (E0), the task (E2), and the task (E3) corresponds. Thus, the state data of the task (E5), the task (E0), the task (E2), and the task (E3) that are elements of the virtual queue (Q0) are adjusted.
図26は、図25に対応した状態レジスタ250のデータ構造図である。
同図において下線を付与している部分が、図24に示した状態レジスタ250の設定内容から変化した箇所である。まず、タスク(E5)の仮想キュー(Q0)への順投入により、キュー識別レジスタ416_E5には新たに「Q0」が設定される。タスク(E5)のODRは「0」、PRは「1」である。タスク(E5)の順投入により、仮想キュー(Q0)に元々投入されていたタスク(E0)、タスク(E1)、タスク(E3)のODRは、それぞれインクリメントされる。
FIG. 26 is a data structure diagram of the
In FIG. 24, the underlined portion is a portion changed from the setting contents of the
図27は、順投入の処理過程を示すフローチャートである。
メイン回路400は、順投入させるタスク(以下、「順投入タスク」とよぶ)についての投入条件を設定する(S10)。具体的には、CMD=ENQ_TLとして、EID_C、QID_C、PR_Cを設定する。キュー制御回路404のうち、順投入タスクに対応するレジスタ値生成回路420は、順投入タスクのタスク優先順位レジスタ412、キュー順序レジスタ414、キュー識別レジスタ416にそれぞれ、PR_C、0、QID_Cを設定する(S12)。
FIG. 27 is a flowchart showing the ordering process.
The
仮想キュー(QID_C)に既に別のタスクが投入されている場合には(S14のY)、既投入の各タスクについてODRをインクリメントする(S16)。図25に示した例の場合、タスク(E0)、タスク(E2)、タスク(E3)について、ODRがインクリメントされる。S12、S14、S16の処理は時間的にほぼ並行して実行される。
[逆投入]
If another task has already been submitted to the virtual queue (QID_C) (Y in S14), the ODR is incremented for each task that has already been submitted (S16). In the case of the example shown in FIG. 25, the ODR is incremented for the task (E0), the task (E2), and the task (E3). The processes of S12, S14, and S16 are executed substantially in parallel in time.
[Reverse input]
図28は、最大値選択回路406の部分的な回路図である。
最大値選択回路406は、逆投入処理のためにメイン回路400により駆動される回路である。最大値選択回路406は、CND信号としてQID_C=Qnを入力されたとき、仮想キュー(Qn)における最大順序値をODR_A2に出力し、ODR_A2_ENをアサートする。最大値選択回路406は、基本例に示した実行選択回路232やセマフォ選択回路234と同じく、複数段の比較回路から構成される。最大値選択回路406は、4つの第1比較回路422(422a、422b等)、2つの第2比較回路424(424a等)、1つの第3比較回路(図示せず)を含む。また、8つの判定回路426(426a、426b、426c、426d等)を含む。
FIG. 28 is a partial circuit diagram of the maximum
The maximum
第1比較回路422aに着目して説明する。第1比較回路422aは、タスク0とタスク1を比較し、どちらも仮想キュー(Qn)に投入されていれば、順序値が大きい方のタスクを選択する。第1比較回路422aには、タスク0とタスク1のタスクIDと順序値がEID_S、ODR_Sとして入力される。
第1の判定:判定回路426aは、タスク0が仮想キュー(Qn)に投入済みであればEID_11A_ENをアサートする。判定回路426bは、タスク1が仮想キュー(Qn)に投入済みであればEID_11B_ENをアサートする。第1比較回路422aは、まず、判定回路426aと判定回路426bのそれぞれから出力されるEID_11_EN信号を参照する。いずれか一方が「1」であれば、いずれか一方のタスクだけが仮想キュー(Qn)に投入されていることになる。このとき、第1比較回路422aは、仮想キュー(Qn)に投入されている方のタスクのタスクID(EID_S)と順序値(ODR_S)をそれぞれEID_21A、ODR_21Aとして出力し、EID_21A_ENをアサートする。
判定回路426aと判定回路426bが共に「0」を出力するときには、どちらのタスクも仮想キュー(Qn)に投入されていない。このとき、EID_21A_ENはネゲートされ、以後、タスク0とタスク1のいずれも第2比較回路424aにおいて考慮の対象とはならない。
判定回路426aと判定回路426bが共に「1」を出力するときには、どちらのタスクも仮想キュー(Qn)に投入済である、このとき、次の第2の判定が実行される。
Description will be made by paying attention to the
First determination: The
When both the
When both the
第2の判定:タスク0のODR_S_0とタスク1のODR_S_1を比較し、順序値が大きい方のタスクを選択する。第1比較回路422aは、順序値が大きい方のタスクのタスクID(EID_S)と順序値(ODR_S)をそれぞれEID_21A、ODR_21Aとして出力し、EID_21A_ENをアサートする。
Second determination: ODR_S_0 of
他の第1比較回路422の処理内容も同様であり、タスク0とタスク1、タスク2とタスク3、タスク4とタスク5、タスク6とタスク7がそれぞれ比較される。第2比較回路424は、2つの第1比較回路422からの出力により、更に順序値が大きい方のタスクを選択する。第2比較回路424aに着目して説明する。第2比較回路424aは、第1比較回路422aの出力信号と第1比較回路422bの出力信号を比較し、順序値が大きい方のタスクを選択する。第2比較回路424aには、第1比較回路422aと第1比較回路422bからそれぞれ、EID_21、ODR_21、EID_ENが入力される。第2比較回路424は、タスク0〜タスク3のうち、仮想キュー(Qn)の中で最も順序値の大きいタスクを選択する。他の第2比較回路424も同様であり、最終的に、仮想キュー(Qn)における最大順序値がODR_A2信号として出力される。いずれかのタスクが選択されたときにはODR_A2_ENはアサートされ、いずれのタスクも仮想キュー(Qn)に存在しないときにはODR_A2_ENはネゲートされる。
なお、第1比較回路422、第2比較回路424、第3比較回路には、優先順位判定を無効化するためのPR無効信号が入力されてもよい。PR無効信号がアサートされているときには、各比較回路は、優先順位を判定条件から除外してタスクを選択する。図32に示す各比較回路についても同様である。
The processing contents of the other first comparison circuits 422 are the same, and
Note that a PR invalid signal for invalidating the priority determination may be input to the first comparison circuit 422, the second comparison circuit 424, and the third comparison circuit. When the PR invalid signal is asserted, each comparison circuit selects a task by excluding priority from the determination conditions. The same applies to each comparison circuit shown in FIG.
図29は、図25の仮想キューにタスク(E6)を逆投入するときの概念図である。
ここでは、仮想キュー(Q0)にタスク優先順位PR=1のタスク(E6)を逆投入するとして説明する。まず、メイン回路400は、投入先のQID=Q0をQID_C信号により最大値選択回路406に入力する。最大値選択回路406は、仮想キュー(Q0)の最大順序値をキュー制御回路404にODR_A2として出力し、ODR_A2_ENをアサートする。図25によると、仮想キュー(Q0)の最大順序値はタスク(E3)の「3」であるため、ODR_A2=3となる。
FIG. 29 is a conceptual diagram when the task (E6) is put back into the virtual queue of FIG.
Here, description will be made assuming that the task (E6) with the task priority order PR = 1 is reversely input to the virtual queue (Q0). First, the
次に、メイン回路400は、CMD=ENQ_TP(逆投入コマンド)として、EID_C=E6、QID_C=Q0、PR_C=1を設定する。このとき、キュー制御回路404に内蔵されるレジスタ値生成回路420_E6は、EID_C=ELM_ID=E6を検出すると、QID_N_E6=QID_C=Q0、ODR_N_E6=ODR_A2+1=3+1=4、PR_N_E6=PR_C=1を出力する。
Next, the
CMD=ENQ_TP(逆投入コマンド)のときには、EID_Cにて指定されたタスクに対応づけられているレジスタ値生成回路420しか動作しない。このため、逆投入されるタスク(E6)の状態データだけが設定変更される。 When CMD = ENQ_TP (reverse input command), only the register value generation circuit 420 associated with the task specified by EID_C operates. For this reason, only the status data of the task (E6) to be reversely input is changed.
図30は、図29に対応した状態レジスタ250のデータ構造図である。
同図において下線を付与している部分が、図26に示した状態レジスタ250の設定内容から変化した箇所である。まず、タスク(E6)の仮想キュー(Q0)への逆投入により、キュー識別レジスタ416_E6には新たに「Q0」が設定される。タスク(E6)のODRは「4」、PRは「1」である。タスク(E6)の逆投入により、他のタスクの状態データは影響を受けない。
FIG. 30 is a data structure diagram of the
In FIG. 26, an underlined portion is a portion changed from the setting contents of the
図31は、逆投入の処理過程を示すフローチャートである。
メイン回路400は、まず、逆投入先となる仮想キューのQID=Qnを最大値選択回路406に入力する(S20)。メイン回路400は、仮想キュー(Qn)の最大順序値をキュー制御回路404に出力する(S22)。メイン回路400は、逆投入させるタスク(以下、「逆投入タスク」とよぶ)についての投入条件を設定する(S24)。具体的には、CMD=ENQ_TP(逆投入コマンド)として、EID_C、QID_C、PR_Cを設定する。キュー制御回路404のうち、逆投入タスクに対応するレジスタ値生成回路420は、逆投入タスクのタスク優先順位レジスタ412、キュー順序レジスタ414、キュー識別レジスタ416にそれぞれ、PR_C、最大順序値+1、QID_Cを設定する(S26)。ただし、最大順序値=0であってODR_A2_ENがネゲートされているとき、すなわち、仮想キュー(Qn)にタスクが未投入であるときには、キュー順序レジスタ414には初投入を示す順序値「0」を設定する。
FIG. 31 is a flowchart showing the reverse charging process.
First, the
以上に示したように、順投入時においては他のタスクの順序値の調整が発生する可能性があるが、逆投入時においてはこのような調整は不要である。FIFOを前提として仮想キューを見たとき、過去に投入されたタスクほど大きな順序値が設定される。いいかえれば、仮想キュー深くに投入されているタスクほど、順序値が大きい。反対に、仮想キュー深くに投入されているタスクほど順序値が小さくなるように設定してもよい。この場合には、順投入時においては他のタスクの順序値の調整は不要となるが、逆投入時においては他のタスクの順序値の調整が発生する可能性がある。
[抽出]
As described above, there is a possibility that the order values of other tasks may be adjusted at the time of sequential input, but such adjustment is not necessary at the time of reverse input. When a virtual queue is viewed on the premise of FIFO, a larger order value is set for a task input in the past. In other words, tasks placed deeper in the virtual queue have a higher order value. On the contrary, it may be set so that the order value becomes smaller as the task is inserted deeper in the virtual queue. In this case, it is not necessary to adjust the order value of other tasks at the time of ordering, but there is a possibility that the order value of other tasks may be adjusted at the time of reverse ordering.
[Extract]
図32は、タスク選択回路230の部分的な回路図である。
タスク選択回路230の基本構成は、基本例として図12に関連して説明した通りである。仮想キュー実装例におけるタスク選択回路230は、メイン回路400からの問い合わせを受けたときに、抽出タスクを特定する。ここでは、この抽出タスクを特定するための仕組みに関わる回路構成について説明する。タスク選択回路230は、CND信号としてQID_C=Qnを入力されたとき、仮想キュー(Qn)において最もタスク優先順位の高い優先キューから抽出タスクを選択し、抽出タスクのタスクID、タスク優先順位、順序値をそれぞれEID_A1、PR_A1、ODR_A1に出力し、EID_A1_ENをアサートする。タスク選択回路230は、基本例に示した実行選択回路232やセマフォ選択回路234と同じく、複数段の比較回路から構成される。タスク選択回路230は、4つの第1比較回路430(430a、430b等)、2つの第2比較回路432(432等)、1つの第3比較回路(図示せず)を含む。また、8つの判定回路434(434a、434b、434c、434d等)を含む。
FIG. 32 is a partial circuit diagram of the
The basic configuration of the
第1比較回路430aに着目して説明する。第1比較回路422aは、タスク0とタスク1を比較し、どちらも仮想キュー(Qn)に投入されていれば、タスク優先順位が高い方のタスクを選択する。タスク優先順位が同じであれば、順序値が大きい方のタスクを選択する。第1比較回路430aには、タスク0とタスク1のタスクID、タスク優先順位、順序値がEID_S、PR_S、ODR_Sとして入力される。
第1の判定:判定回路434aは、タスク0が仮想キュー(Qn)に投入済みであればEID_11A_ENをアサートする。判定回路434bは、タスク1が仮想キュー(Qn)に投入済みであればEID_11B_ENをアサートする。第1比較回路430aは、まず、判定回路434aと判定回路434bのそれぞれから出力されるEID_11_EN信号を参照する。いずれか一方が「1」であれば、いずれか一方のタスクだけが仮想キュー(Qn)に投入されていることになる。このとき、第1比較回路430aは、仮想キュー(Qn)に投入されている方のタスクのタスクID(EID_S)、タスク優先順位(PR_S)および順序値(ODR_S)をそれぞれEID_21A、PR_11A、ODR_21Aとして出力し、EID_21A_ENをアサートする。
判定回路434aと判定回路434bが共に「0」を出力するときには、どちらのタスクも仮想キュー(Qn)に投入されていない。このとき、EID_21A_ENはネゲートされ、以後、タスク0とタスク1のいずれも第2比較回路432aにおいて考慮の対象とはならない。
判定回路434aと判定回路434bが共に「1」を出力するときには、どちらのタスクも仮想キュー(Qn)に投入済である、このとき、次の第2の判定が実行される。
Description will be made by paying attention to the
First determination: The
When both the
When both the
第2の判定:タスク0のPR_S_0とタスク1のPR_S_1を比較し、タスク優先順位が高い方、いいかえれば、PR_Sが小さい方のタスクを選択する。第1比較回路430aは、タスク優先順位が高い方のタスクのタスクID(EID_S)、タスク優先順位(PR_S)および順序値(ODR_S)をそれぞれEID_21A、PR_21A、ODR_21Aとして出力し、EID_21A_ENをアサートする。2つのタスクのタスク優先順位が同じであれば、次の第3の判定が実行される。
Second determination: PR_S_0 of
第3の判定:タスク0のODR_S_0とタスク1のODR_S_1を比較し、順序値が大きい方のタスクを選択する。第1比較回路430aは、順序値が大きい方のタスクのタスクID(EID_S)、タスク優先順位(PR_S)と順序値(ODR_S)をそれぞれEID_21A、PR_21A、ODR_21Aとして出力し、EID_21A_ENをアサートする。
Third determination: ODR_S_0 of
他の第1比較回路430の処理内容も同様であり、タスク0とタスク1、タスク2とタスク3、タスク4とタスク5、タスク6とタスク7がそれぞれ比較される。第2比較回路432は、2つの第1比較回路430からの出力により、更に抽出タスクの候補を絞り込む。最終的に、仮想キュー(Qn)において最もタスク優先順位の高い優先キューから、抽出タスクが選択される。いずれかのタスクが選択されたときにはEID_A1_ENはアサートされ、いずれのタスクも仮想キュー(Qn)に存在しないときにはEID_A1_ENはネゲートされる。
The processing contents of the other first comparison circuits 430 are the same, and
図33は、図29の仮想キューからタスク(E3)を抽出するときの概念図である。
こでは、仮想キュー(Q0)からタスクを1つ抽出するとして説明する。メイン回路400は、QID_C=Q0をタスク選択回路230に入力する。図29によると、仮想キュー(Q0)のうち最も高いタスク優先順位に対応する優先キュー(Q0:0)には、順序値「1」のタスク(E0)と順序値「3」のタスク(E3)が投入されている。タスク選択回路230は、順序値が大きい方のタスク(E3)を抽出タスクとして選択する。タスク選択回路230は、EID_A1=E3、PR_A1=0、ODR_A1=3として、EID_A1_ENをアサートする。
FIG. 33 is a conceptual diagram when the task (E3) is extracted from the virtual queue of FIG.
Here, a description will be given assuming that one task is extracted from the virtual queue (Q0). The
次に、メイン回路400は、CMD=DEQ(抽出コマンド)として、EID_C=EID_A1=E3、QID_C=Q0を設定する。レジスタ値生成回路420_E3は、QID_N_E3=Non、ODR_N_E3=0(リセット)、PR_N_E3=0(リセット)を出力する。こうして、タスク(E3)と仮想キュー(Q0)との関係が状態レジスタ250において解消される。
Next, the
レジスタ値生成回路420_E3だけでなく、QID_S_En=QID_C=Q0となるレジスタ値生成回路420_Enは、QID_C=QID_S_Enを検出すると、ODR_S_En>ODR_A1となるか判定する。ここでは、ODR_A1は、抽出タスク(E3)の抽出前の順序値である。ODR_S_En>ODR_A1であれば、すなわち、抽出タスクの順序値よりも順序値が大きいタスク(En)のレジスタ値生成回路420_Enは、ODR_N_En=ODR_S_En−1を出力する。図29に示す例では、タスク(E6)についてのレジスタ値生成回路420_E6が該当する。レジスタ値生成回路420_E6は、ODR_N_E6=ODR_S_E6−1=4−1=3を出力する。こうして、仮想キュー(Q0)の要素であるタスク(E6)の状態データが調整される。 Not only the register value generating circuit 420_E3 but also the register value generating circuit 420_En that satisfies QID_S_En = QID_C = Q0 determines whether or not ODR_S_En> ODR_A1 when detecting QID_C = QID_S_En. Here, ODR_A1 is an order value before extraction of the extraction task (E3). If ODR_S_En> ODR_A1, that is, the register value generation circuit 420_En of the task (En) whose order value is larger than the order value of the extracted task outputs ODR_N_En = ODR_S_En-1. In the example shown in FIG. 29, the register value generation circuit 420_E6 for the task (E6) corresponds. The register value generation circuit 420_E6 outputs ODR_N_E6 = ODR_S_E6-1 = 4-1 = 3. Thus, the state data of the task (E6) that is an element of the virtual queue (Q0) is adjusted.
図34は、図33に対応した状態レジスタ250のデータ構造図である。
同図において下線を付与している部分が、図30に示した状態レジスタ250の設定内容から変化した箇所である。まず、タスク(E3)の仮想キュー(Q0)からの抽出により、キュー識別レジスタ416_E3には新たに「Non」が設定される。また、キュー順序レジスタ414とタスク優先順位レジスタ412にはそれぞれリセット値として「0」が設定される。タスク(E3)の抽出により、仮想キュー(Q0)に元々投入されていたタスク(E0)、タスク(E2)、タスク(E5)、タスク(E6)のうち、抽出タスク(E3)よりも順序値が大きかったタスク(E6)のODRはデクリメントされる。
FIG. 34 is a data structure diagram of the
In the figure, the underlined portion is a portion changed from the setting contents of the
図35は、抽出の処理過程を示すフローチャートである。
メイン回路400は、まず、抽出先となる仮想キューのQID=Qnをタスク選択回路230に入力する(S30)。タスク選択回路230は、仮想キュー(Qn)から抽出タスクを選択する(S32)。メイン回路400は、抽出タスクのタスクID=Enをキュー制御回路404に入力すると、キュー制御回路404は、抽出タスク(En)の状態データからQID=Qnをクリアする(S34)。このとき、PRやODRを「0」にリセットするが、必ずしもリセットはしなくてもよい。
FIG. 35 is a flowchart showing the extraction process.
First, the
仮想キュー(Qn)に他のタスクも投入されており(S36のY)、ODR_S_En>ODR_A1となるタスクが存在するときには(S38のY)、該当タスクの順序値をデクリメントする(S40)。なお、S30からS40に示した処理はシリアル実行される必要はなく、時間的に並行して実行してもよい。
実装上、仮想キューの途中からでもタスクを取り出すことができる。たとえば、図33において、仮想キュー(Q0)の真ん中からタスク(E2)を取り出す必要が発生したとする。タスク(E2)は、あるフラグAがオンに設定されていることを条件として動作可能なタスクであるとする。このフラグAがオフにされたとき、タスク(E2)を仮想キュー(Q0)の途中から取り出す必要が発生する。あるいは、タスク(E2)についてあらかじめ設定されていた待ち時間がタイムアウトしたときにも、タスク(E2)を仮想キュー(Q0)の途中から取り出す必要が発生する。この場合には、タスク(E2)のQIDをクリアし、タスク(E2)の順序値「2」よりも順序値が大きいタスクのODRをデクリメントすることにより、タスク(E2)を仮想キュー(Q0)の途中からでも取り出すことができる。図33の場合、タスク(E6)のODRが「2」となる。仮想キューがハードウェアによって物理的な制約を受けないかたちで形成されるため、キューの途中からでも投入・抽出処理が可能となる。
When other tasks are also put in the virtual queue (Qn) (Y in S36) and there is a task satisfying ODR_S_En> ODR_A1 (Y in S38), the order value of the corresponding task is decremented (S40). Note that the processing shown in S30 to S40 need not be executed serially, and may be executed in parallel in time.
In terms of implementation, tasks can be taken out from the middle of the virtual queue. For example, in FIG. 33, it is assumed that the task (E2) needs to be taken out from the middle of the virtual queue (Q0). The task (E2) is assumed to be an operable task on condition that a certain flag A is set to ON. When the flag A is turned off, the task (E2) needs to be taken out from the middle of the virtual queue (Q0). Alternatively, it is necessary to take out the task (E2) from the middle of the virtual queue (Q0) even when the waiting time set in advance for the task (E2) times out. In this case, the QID of the task (E2) is cleared, and the task (E2) is decremented by the ODR of the task having an order value larger than the order value “2” of the task (E2). It can be taken out even from the middle. In the case of FIG. 33, the ODR of the task (E6) is “2”. Since the virtual queue is formed in such a way that it is not physically restricted by hardware, it is possible to perform input / extraction processing even from the middle of the queue.
以上に示す仮想キュー制御によれば、FIFOを基本としつつも、LIFO的な動作を実現する特殊なキューをハードウェア・ロジックにより実現できる。両投入型キューアルゴリズムをソフトウェアで実装するとすれば、通常、連結リストによる実装となる。しかし、ソフトウェアによる処理である限り、メモリへのアクセスやアドレスの管理にともなうオーバーヘッドが発生せざるを得ない。これに対して、仮想キュー実装例に示す仮想キュー制御は、ハードウェア・ロジックにより実現されるため、格段にシンプルで高速な制御が可能となる。特に、時間的要件が厳しいRTOSにおいては、両投入型キューアルゴリズムをハードウェア実装する意義は大きい。次に、再実行優先型タスクスケジューリングを上述した仮想キュー制御方法により実現する態様について説明する。 According to the virtual queue control described above, a special queue that realizes LIFO-like operation can be realized by hardware logic while being based on FIFO. If the double-throw queue algorithm is implemented by software, it is usually implemented by a linked list. However, as long as the processing is performed by software, overhead associated with memory access and address management must be generated. On the other hand, since the virtual queue control shown in the virtual queue implementation example is realized by hardware logic, it is possible to perform much simpler and faster control. In particular, in RTOS where time requirements are strict, it is significant to implement the double-throw queue algorithm in hardware. Next, an aspect in which the re-execution priority type task scheduling is realized by the above-described virtual queue control method will be described.
図36は、再実行優先型タスクスケジューリングにおける仮想キューとタスクの関係を示す第1の概念図である。
ここでは、READY状態に対応する仮想キュー(Q0)とWAITセマフォ状態に対応する仮想キュー(Q1)の2つの仮想キューを想定している。仮想キュー(Q0)は、タスク優先順位PR=0のタスクを投入するための優先キュー(以下、「優先キュー(Q0:0)」と表記する)とタスク優先順位PR=1のタスクを投入するための優先キュー(Q0:1)の2つの優先キューの集合体である。仮想キュー(Q1)についても同様であり、実質的には4つの優先キューが想定される。
FIG. 36 is a first conceptual diagram showing the relationship between virtual queues and tasks in re-execution priority task scheduling.
Here, two virtual queues are assumed, a virtual queue (Q0) corresponding to the READY state and a virtual queue (Q1) corresponding to the WAIT semaphore state. The virtual queue (Q0) inputs a priority queue (hereinafter referred to as “priority queue (Q0: 0)”) for inputting a task having a task priority order PR = 0 and a task having a task priority order PR = 1. It is an aggregate of two priority queues for priority queues (Q0: 1) for The same applies to the virtual queue (Q1), and substantially four priority queues are assumed.
同図においては、PR=1のタスク(E1)がRUN状態にあり、同じくPR=1のタスク(E0)、タスク(E2)は、優先キュー(Q0:1)にてREADY状態として待機している。また、PR=0のタスク(E3)は、優先キュー(Q1:0)にてWAITセマフォ状態にて待機している。ここで、タスク(E1)は、いったん実行されたら集中的・優先的に実行させたいタスクであるとする。 In this figure, the task (E1) with PR = 1 is in the RUN state, and the task (E0) and task (E2) with PR = 1 are also waiting in the READY state in the priority queue (Q0: 1). Yes. Further, the task (E3) with PR = 0 is waiting in the WAIT semaphore state in the priority queue (Q1: 0). Here, it is assumed that the task (E1) is a task to be executed intensively and preferentially once it is executed.
まず、RUN状態のタスク(E1)がリリースセマフォシステムコールを実行して、READY状態に戻るとする(S1)。タスク(E1)はなるべく早い段階で再実行させたいタスクであるため、優先キュー(Q0:1)に「逆投入」される。一方、リリースセマフォシステムコールにより、タスク(E3)のWAIT解除条件が成立したとする。タスク(E3)は優先キュー(Q1:0)から抽出され、優先キュー(Q0:0)に順投入される(S2)。次に、タスク選択回路230は、新たなRUN−タスクを選択する。タスク選択回路230は、READY状態にあるタスクのうち、タスク優先順位が最も高いタスク(E3)を抽出タスクとして選択する。こうして、WAIT状態からREADY状態に移行したばかりのタスク(E3)は、優先キュー(Q0:0)から抽出されて新たなRUN−タスクとなる。このようなタスクスケジューリングによれば、タスク優先順位が高いタスクは、WAIT解除条件が成立すれば比較的早い段階で実行権を取得できる。
First, it is assumed that the task (E1) in the RUN state executes a release semaphore system call and returns to the READY state (S1). Since the task (E1) is a task that is to be re-executed at the earliest possible stage, it is “reversely input” to the priority queue (Q0: 1). On the other hand, it is assumed that the WAIT cancellation condition for the task (E3) is satisfied by the release semaphore system call. The task (E3) is extracted from the priority queue (Q1: 0) and sequentially entered into the priority queue (Q0: 0) (S2). Next, the
図37は、再実行優先型タスクスケジューリングにおける仮想キューとタスクの関係を示す第2の概念図である。
タスク(E3)がウェイトセマフォシステムコールを実行すると、タスク(E3)は優先キュー(Q1:0)に順投入される(S4)。次に、タスク選択回路230は新たなRUN−タスクを選択する。タスク選択回路230は、READY状態にあるタスクのうち、タスク優先順位が最も高いタスクを選択するが、ここではタスク(E0)、タスク(E2)、タスク(E1)のタスク優先順位は同じである。この場合、優先キュー(Q0:1)からタスク(E1)が抽出される(S5)。タスク(E1)は、新たなRUN−タスクとなる。このような処理方法によれば、タスク優先順位PR=0を設定するほどではないが、いったん実行されたらなるべく連続的に実行させたいというタスク(E1)の仕様に対応できる。
FIG. 37 is a second conceptual diagram showing the relationship between virtual queues and tasks in re-execution priority task scheduling.
When the task (E3) executes the wait semaphore system call, the task (E3) is sequentially placed in the priority queue (Q1: 0) (S4). Next, the
再実行優先型タスクスケジューリングでは、実行状況やタスクの種類に応じて、順投入と逆投入を使い分けることにより、タスクの実行順位を制御できる。このため、基本例に示したタスク処理装置100の高速処理性能という特徴を維持しつつも、より精緻なタスクスケジューリングを実現できる。
{HW割込実装例(SPシステム)}
In the re-execution priority type task scheduling, the task execution order can be controlled by properly using the forward input and reverse input according to the execution status and the type of task. For this reason, more precise task scheduling can be realized while maintaining the feature of high-speed processing performance of the
{HW interrupt implementation example (SP system)}
次に、HW割込実装例として、割り込み処理をハードウェア・ロジックにより実現するタスク処理装置100について説明する。
Next, a
図38は、一般的なソフトウェアOSによる割り込み処理のタイムチャートである。
ソフトウェアOSは、割込コントローラ(図示せず)から割込要求信号を受信すると、割込ハンドラ、すなわち、基本例でいう特殊タスクを起動する。キーボード押下、通信パケットの受信、DMA転送の完了、あるいは、単なる所定時間の経過といったさまざまな事象が割込要求信号の発生契機となり得る。特殊タスクはソフトウェアにより実装されるタスクであり、割込要因に対応してさまざまな割り込み処理を実行する。
FIG. 38 is a time chart of interrupt processing by a general software OS.
When the software OS receives an interrupt request signal from an interrupt controller (not shown), the software OS starts an interrupt handler, that is, a special task in the basic example. Various events such as pressing of the keyboard, reception of a communication packet, completion of DMA transfer, or mere passage of a predetermined time can trigger an interrupt request signal. A special task is a task implemented by software, and executes various interrupt processes corresponding to interrupt factors.
同図においては、まず、一般タスク実行中に割込要求信号INTR検出されている。即時対応すべき割込要求信号である場合、実行中の一般タスクは中断され、OSに実行権が移る(S100)。OSは、一般タスクのコンテキスト情報をTCBに退避させ(S102)、特殊タスクを起動する(S104)。 In the figure, first, an interrupt request signal INTR is detected during execution of a general task. If it is an interrupt request signal that should be dealt with immediately, the general task being executed is interrupted and the execution right is transferred to the OS (S100). The OS saves the context information of the general task in the TCB (S102) and activates the special task (S104).
特殊タスクは、割込要因を解析する(S106)。割込要求信号により割込要因レジスタ(図示せず)へのさまざまな書き込みが実行されるため、割込要因レジスタを調べることにより割込要因を特定できる。特殊タスクは、割込要因に対応して実行すべき割り込み処理を判定し、割り込み処理を開始する。割り込み処理の過程においてはさまざまなシステムコール命令が実行されることになる。システムコール命令を実行するとき、再び、OSに実行権が移る(S108)。OSは、指定されたシステムコールを実行する(S110)。システムコール実行後、特殊タスクに実行権が再移行する(S112)。割り込み処理は優先度の高い処理であるため、通常、特殊タスクの処理が完了しない限り、一般タスクに実行権が移ることはない。 The special task analyzes the interrupt factor (S106). Since various writes to the interrupt factor register (not shown) are executed by the interrupt request signal, the interrupt factor can be specified by examining the interrupt factor register. The special task determines the interrupt process to be executed in response to the interrupt factor, and starts the interrupt process. Various system call instructions are executed in the process of interrupt processing. When the system call instruction is executed, the execution right is transferred again to the OS (S108). The OS executes the designated system call (S110). After executing the system call, the execution right is transferred again to the special task (S112). Since the interrupt process is a high-priority process, the execution right is not normally transferred to the general task unless the special task process is completed.
特殊タスクは、割り込み処理を継続し(S114)、再びシステムコール命令を実行するときには、OSに実行権が移行する(S116)。このように特殊タスクとOSが交代で実行権を取得しながら、特殊タスクに最後の実行権が移行し(S118)、特殊タスクは割り込み処理を完了する(S120)。割り込み処理が完了すると、OSに実行権が移行し(S122)、特殊タスクから一般タスクへのタスクスイッチが実行される(S124)。こうして、一般タスクによる通常処理が再開されることになる(S126)。 The special task continues the interrupt process (S114), and when executing the system call instruction again, the execution right is transferred to the OS (S116). As described above, while the special task and the OS alternately acquire the execution right, the last execution right shifts to the special task (S118), and the special task completes the interrupt process (S120). When the interrupt process is completed, the execution right is transferred to the OS (S122), and a task switch from the special task to the general task is executed (S124). Thus, normal processing by the general task is resumed (S126).
基本例や仮想キュー実装例に示したタスク処理装置100は、RTOSとしての機能をハードウェア・ロジックにより実現している点がソフトウェアOSと異なるが、割り込み処理における基本的な流れはソフトウェアOSとほぼ同様である。ただし、基本例に関連して説明したように、S102やS124におけるタスクスイッチやS110等のシステムコール実行は、ソフトウェアOSに比べて格段に高速化される。
基本例のタスク処理装置100の場合、S100、S108、S116、S122にてCPUクロック(CLK)を停止させた上で、RTOSの処理が実行されることになる。また、S104、S112、S118、S126によりCPUクロック(CLK)を再開せた上で、特殊タスクや一般タスクの処理が実行されることになる。特殊タスクは、タスク優先順位が特に高いタスクであるが、CPUクロック(CLK)にしたがって動作するコンテキストベースのタスクである点では一般タスクと同じである。
The
In the case of the basic example
HW割込実装例においては、このような割り込み処理、具体的には特殊タスクの機能の一部をハードウェア・ロジックにより実現することにより、割り込み処理を更に高速化する。 In the HW interrupt implementation example, such interrupt processing, specifically, a part of the function of the special task is realized by hardware logic, thereby further speeding up the interrupt processing.
割り込み処理の内容はさまざまであるが、割込要求信号によっては、単純で定型的な処理内容となることも多い。たとえば、ある一般タスクAがDMA転送を開始し、DMA転送の完了を待つという状況を想定する。一般タスクAはDMA転送開始時において、ウェイトイベントシステムコールを実行して、WAIT状態に移行する。DMA転送が完了すると、所定の割込要求信号が(基本例の)タスク切換回路210に入力される。このとき起動される特殊タスクは、セットイベントシステムコールを実行して、DMA転送完了の旨を示すフラグパターンをイベントテーブル214に設定する。イベントテーブル214のカレントフラグパターンが変化することにより、一般タスクAのWAIT解除条件が成立し、一般タスクAはREADY状態に移行する。このように、DMA転送完了にともなって実行される割り込み処理の内容は比較的単純である。 The contents of the interrupt process vary, but depending on the interrupt request signal, the process contents are often simple and routine. For example, assume a situation where a general task A starts DMA transfer and waits for completion of DMA transfer. At the start of DMA transfer, the general task A executes a wait event system call and shifts to the WAIT state. When the DMA transfer is completed, a predetermined interrupt request signal is input to the task switching circuit 210 (in the basic example). The special task activated at this time executes a set event system call and sets a flag pattern indicating completion of DMA transfer in the event table 214. When the current flag pattern in the event table 214 changes, the WAIT cancellation condition for the general task A is satisfied, and the general task A shifts to the READY state. As described above, the contents of the interrupt process executed upon completion of the DMA transfer are relatively simple.
そこで、HW割込実装例におけるタスク処理装置100は、割り込み処理の内容が比較的単純であり、好ましくは発生頻度の高い割込要求信号を「高速割込要求信号INTR(H)」として事前に登録しておく。HW割込実装例における割込要求信号は高速割込要求信号INTR(H)と「通常割込要求信号INTR(N)」の2種類に大別される。
Therefore, the
図39は、HW割込実装例におけるタスク処理装置100の回路図である。
HW割込実装例におけるタスク処理装置100も、CPU150に加えて退避回路120とタスク制御回路200を含む。HW割込実装例におけるタスク処理装置100には、更に、割込回路450が追加される。
FIG. 39 is a circuit diagram of the
The
高速割込要求信号INTR(H)は、割込回路450に入力される。割込回路450の構成および割込回路400による高速割込要求信号の処理方法については、後述する。通常割込要求信号INTR(N)は、基本例と同じく、タスク切換回路210に直接入力され、特殊タスクにより割り込み処理される。高速割込要求信号についての割り込み処理(以下、「高速割り込み処理」とよぶ)は通常割込要求信号についての割り込み処理(以下、「通常割り込み処理」とよぶ)よりも高速である。一方、通常割り込み処理の場合には、ソフトウェアの特殊タスクとして処理内容の詳細を柔軟に定義できるというメリットがある。HW割込実装例におけるタスク処理装置100は、高速割込要求信号と通常割込要求信号を併用することにより、RTOSとしての汎用性を維持しつつ高速化を図っている。
The high speed interrupt request signal INTR (H) is input to the interrupt
図40は、割込回路450の回路図である。
割込回路450は、信号選択回路452、操作回路454および記憶部456を含む。INTR(H)_0〜INTR(H)_i−1のi個の高速割込要求信号は、不定期的に信号選択回路452に入力される。短期間に複数の高速割込要求信号INTR(H)が入力されることもあるし、同時に複数の高速割込要求信号INTR(H)が入力されることもある。信号選択回路452は、受信した高速割込要求信号INTR(H)を一時的に蓄積できる。
FIG. 40 is a circuit diagram of the interrupt
The interrupt
信号選択回路452は、バッファリングしている高速割込要求信号INTR(H)の中から1つの高速割込要求信号INTR(H)を所定の選択規則に基づいて選択する。ここでいう選択規則は、設計要件に応じて任意に決定されればよい。たとえば、高速割込要求信号INTR(H)ごとに優先順位を設定しておき、複数の高速割込要求信号INTR(H)がバッファリングされているときには、そのうち優先順位が最も高い高速割込要求信号INTR(H)を選択するとしてもよい。あるいは、信号選択回路452への入力タイミングが最も古い高速割込要求信号INTR(H)を選択するとしてもよいし、ランダムに選択するとしてもよい。高速割込要求信号INTR(H)_n(nは0〜i-1までの整数)が選択されると、信号選択回路452は、対応する信号QINT_nをアサートする。
The
操作回路454は、QINT_nをアサートされると、ISROP信号をアサートする。ISROP信号のアサートにより、高速割り込み処理中であることが信号選択回路452に伝えられる。ISROP信号がアサートされると、ISROP信号がネゲートされるまで信号選択回路452は次のQINTをアサートしない。ISROP信号がネゲートされると、信号選択回路452は次の処理対象となる高速割込要求信号INTR(H)を選択可能となる。
When QINT_n is asserted, the
QINT_nがアサートされると、操作回路454は、高速割り込み処理の実行をタスク切換回路210に要求するためにISR_RQもアサートする。ISR_RQがアサートされると、タスク切換回路210は、CPUクロック(CLK)を供給停止させる。こうして、一般タスクは実行停止される。
When QINT_n is asserted, the
操作回路454は、QINT_nに応じて、いいかえれば、選択された高速割込要求信号INTR(H)_nに応じて、DSC_ADD[k−1:0]に所定のアドレスADD[n]を設定する。DSC_ADD[k−1:0]=ADD[n]の入力により、記憶部456のアドレスADD[n]に保持されている割込操作命令p0がISR_DT[31:0]としてタスク切換回路210に送信される。タスク切換回路210は、受信した割込操作命令p0にしたがって高速割り込み処理を実行する。
The
本実施例における割込操作命令は、図42にて後述するように32ビットサイズに正規化されており、その最上位ビットISR_DT[31]により、後続の割込操作命令の存否が示される。なお、割込操作命令は、64ビット、128ビット等、32ビット以外の任意のサイズにて正規化されてもよい。最上位ビットISR_DT[31]=1のときには、タスク切換回路210はISR_NXをアサートして、後続の割込操作命令p1を操作回路454に要求する。操作回路454は、先ほどのアドレスADD[n]に1ワード(本実施例においては32ビット)を加算したアドレスADD[n]+1をDSC_ADD[k−1:0]に設定する。アドレスADD[n]+1に保持されている割込操作命令p1がISR_DT[31:0]としてタスク切換回路210に送信される。タスク切換回路210は、受信した割込操作命令p1にしたがって高速割り込み処理を続行する。
The interrupt operation instruction in this embodiment is normalized to a 32-bit size as will be described later with reference to FIG. 42, and the most significant bit ISR_DT [31] indicates the presence or absence of a subsequent interrupt operation instruction. Note that the interrupt operation instruction may be normalized with an arbitrary size other than 32 bits, such as 64 bits and 128 bits. When the most significant bit ISR_DT [31] = 1, the
最上位ビットISR_DT[31]=0のときには、タスク切換回路210はISR_ENDをアサートして、高速割り込み処理の完了を操作回路454に通知する。操作回路454は、ISROPをネゲートする。ISROPがネゲートされると、信号選択回路452は、別の高速割込要求信号INTR(H)を選択して、新たにQINTをアサート可能となる。
なお、HW割込実装例においては、ISR_END信号が操作回路454に入力され、操作回路454がISROPをネゲートすることにより、信号選択回路452を制御している。変形例として、タスク切換回路210は、高速割り込み処理が完了したときには、直接、信号選択回路452にISR_END信号を送信して、信号選択回路452を制御してもよい。
When the most significant bit ISR_DT [31] = 0, the
In the HW interrupt implementation example, the ISR_END signal is input to the
図41は、記憶部456のデータ構造図である。
HW割込実装例における記憶部456は、メモリである。アドレス「0x000〜0x0FF」には、高速割込要求信号INTR(H)_0に対応した割込操作命令群が保持されている。同様にして、アドレス「0x100〜0x1FF」には、高速割込要求信号INTR(H)_1に対応した割込操作命令群が保持されている。HW割込実装例における割込操作命令は、システムコール命令である。たとえば、信号選択回路452が高速割込要求信号INTR(H)_0を選択すると、操作回路454は高速割込要求信号INTR(H)_0の最初のアドレスである「0x000」をDSC_ADD[k−1:0]に指定する。記憶部456からは、該当する割込操作命令「systemcall_00」がタスク切換回路210に送信される。割込操作命令「systemcall_00」には、後続の割込操作命令「systemcall_01」が存在するため、割込操作命令「systemcall_00」の最上位ビットには「1」が設定されている。タスク切換回路210は、割込操作命令「systemcall_00」を実行したあと、後続の割り込み操作命令を要求するためにISR_NXをアサートする。
FIG. 41 is a data structure diagram of the
The
操作回路454は「0x000」に1ワードを加算したアドレス「0x001」をDSC_ADD[k−1:0]に新たに指定する。記憶部456からは、続きの割込操作命令「systemcall_01」がタスク切換回路210に送信されることになる。「syscall_01」の最上位ビットは「0」にセットされており、タスク切換回路210は、高速割込要求信号INTR(H)_0についての高速割り込み処理として、「syscall_01」が最後の割込操作命令であることを認識できる。タスク切換回路210は、割込操作命令「syscall_01」の実行を完了すると、ISR_ENDをアサートして、高速割り込み処理の終了を通知する。
The
図42は、割込操作命令のデータ構造を示す。
先述のように、ISR_DT[31]は後続の割込操作命令の有無を示す。ISR_DT[30:24]により、システムコールの種類が示される。ISR_DT[30:24]=0000001は「セットイベントシステムコール」を示す。このため、割込操作命令460aはセットイベントシステムコールの実行命令である。ISR_DT[23:8]はセットフラグパターン、ISR_DT[7:0]はイベントIDを示す。タスク切換回路210は、割込操作命令460aを受信すると、基本例と同様の処理方法にてイベントテーブル214を設定する。
FIG. 42 shows the data structure of an interrupt operation instruction.
As described above, ISR_DT [31] indicates the presence / absence of a subsequent interrupt operation instruction. The type of system call is indicated by ISR_DT [30:24]. ISR_DT [30:24] = 0000001 indicates a “set event system call”. Therefore, the interrupt
ISR_DT[30:24]=0000010は「リリースセマフォシステムコール」を示す。このため、割込操作命令460bはリリースセマフォシステムコールの実行命令である。ISR_DT[7:0]は、解放セマフォのセマフォIDを示す。ISR_DT[30:24]=0000011は「リリースウェイトシステムコール」を示す。このため、割込操作命令460cはリリースウェイトシステムコールの実行命令である。ISR_DT[4:0]は、WAIT状態から解放すべきタスクのタスクIDを示す。ISR_DT[30:24]=0000100は「ウェイクアップタスクシステムコール」を示す。このため、割込操作命令460dはウェイクアップタスクシステムコールの実行命令である。ISR_DT[4:0]は、WAIT状態から解放すべきタスクのタスクIDを示す。ISR_DT[30:24]=0000101は「起動システムコール」を示す。このため、割込操作命令460eは起動システムコールの実行命令である。ISR_DT[4:0]は、起動すべきタスクのタスクIDを示す。このほかにもさまざまなシステムコールが割込操作命令として記憶部406に登録されてもよい。
ISR_DT [30:24] = 0000010 indicates a “release semaphore system call”. Therefore, the interrupt
記憶部456は、ROM(Read Only Memory)として提供されてもよいし、読み書き可能なRAM(Random Access Memory)として提供されてもよい。記憶部456の内容をアプリケーションにより書き換え可能であれば、高速割り込み処理の内容をソフトウェアにより設定変更できる。
The
図43は、高速割り込み処理の過程を示すシーケンス図である。
まず、信号選択回路452は、処理対象となる高速割込要求信号INTR(H)_nを選択し(S130)、QINT_nをアサートする(S132)。操作回路454は、ISROPをアサートして、高速割り込み処理の最中である旨を信号選択回路452に通知する(S134)。信号選択回路452は、ISROPをアサートされると、新たな高速割込要求信号を受信しても、バッファリングしておき、QINTをアサートすることはない。
FIG. 43 is a sequence diagram showing the process of high-speed interrupt processing.
First, the
一方、操作回路454は、QINT_nをアサートされると、ISR_RQをアサートして、高速割り込み処理の開始をタスク切換回路210に要求する(S136)。このとき、タスク切換回路210は、CPUクロック(CLK)を停止させ、高速割り込み処理の開始に備える。操作回路454は、QINT_nに対応するアドレスADD[n]をDSC_ADDに指定して、記憶部456から割込操作命令p0を読み出す(S138)。割込操作命令p0は、ISR_DT[31:0]として、タスク切換回路210に送信される(S140)。
On the other hand, when QINT_n is asserted, the
タスク切換回路210は、受信した割込操作命令p0にしたがって、セマフォテーブル212やイベントテーブル214、状態記憶部220の設定内容を変更する。より具体的には、タスク切換回路210は、一般タスクが、リリースセマフォシステムコール(シグナリングセマフォシステムコール)やセットイベントシステムコール(セットフラグシステムコール)を発行するときと同等の処理プロセスを実行することにより、セマフォテーブル212やイベントテーブル214、状態記憶部220の設定内容を変更する。割込操作命令の処理内容については、基本例に示したシステムコール命令の処理内容と同様である。割込操作命令の最上位ビットに「1」が設定されていれば、タスク切換回路210は、ISR_NXをアサートして次の割込操作命令p1を操作回路454に要求する(S144)。操作回路454は、次の割込操作命令p1をロードし(S146)、割込操作命令p1はタスク切換回路210に送信される(S148)。
The
タスク切換回路210が最後の割込操作命令pxを実行したとき、すなわち、最上位ビットに「0」が設定されている割込操作命令pxを実行したとき、タスク切換回路210はISR_ENDをアサートする(S152)。操作回路454は、高速割り込み処理の完了を認識し、ISROPをネゲートする(S154)。こうして、信号選択回路452は次の高速割込要求信号を選択可能となる。
When the
図44は、HW割込実装例におけるタスク切換回路210の状態遷移図である。
HW割込実装例においては、図15に示した状態遷移図に加えて、高速割り込み処理(A6)が追加されている。また、通常割り込み処理(A3)は、図15に示した割り込み処理(A3)と同じである。そのほかにも、基本例と同一の符号を付した構成は、同一の処理内容を示している。
FIG. 44 is a state transition diagram of the
In the HW interrupt implementation example, in addition to the state transition diagram shown in FIG. 15, high-speed interrupt processing (A6) is added. The normal interrupt process (A3) is the same as the interrupt process (A3) shown in FIG. In addition, the configuration denoted by the same reference numerals as the basic example indicates the same processing content.
タスク実行中(A2)において、高速割込要求信号INTR(H)が検出されると(S24)、ISR_RQがアサートされて、高速割り込み処理(A6)が実行される。割込回路400がタスク切換回路210に割込操作命令を送信すると(S26)、タスク切換回路210は対応したシステムコール処理(A4)を実行する。システムコール命令の実行が完了すると、高速割り込み処理(A6)に状態遷移する(S28)。更に処理すべき割込操作命令が残っていなければ、高速割り込み処理は終了して(S30)、次に実行すべき一般タスクが選択される(A5)。
If a high-speed interrupt request signal INTR (H) is detected during task execution (A2) (S24), ISR_RQ is asserted and high-speed interrupt processing (A6) is executed. When the interrupt
図45は、HW割込実装例のタスク処理装置100による高速割り込み処理の処理過程を示すタイムチャートである。
同図においては、まず、一般タスク実行中に割込要求信号INTRが検出されている。即時対応すべき割込要求信号である場合、CPUクロック(CLK)の停止により、実行中の一般タスクは中断され、割込回路450とタスク切換回路210による高速割り込み処理が開始される(S160)。
FIG. 45 is a time chart showing the process of high-speed interrupt processing by the
In the figure, first, an interrupt request signal INTR is detected during execution of a general task. If the interrupt request signal is to be dealt with immediately, the general task being executed is interrupted by stopping the CPU clock (CLK), and high-speed interrupt processing by the interrupt
割込回路450は、適宜、割込操作命令を読み出し、タスク切換回路210が割込操作命令として指定されるシステムコール命令を実行する。こうして一連のシステムコールにより実現される高速割り込み処理が完了すると(S162)、タスク切換回路210は次のRUN−タスクを選択する(S164)。選択後、CPUクロック(CLK)が再開され、一般タスクによる通常処理が再開される(S166)。
The interrupt
HW割込実装例に示したタスク処理装置100によれば、高速割り込み処理を割込回路450とタスク切換回路210の協働によりハードウェア・レベルで実現できる。本発明者らの実験によると、基本例におけるタスク処理装置100に比べて、HW割込実装例におけるタスク処理装置100は更に約4倍の速度で動作することが確認されている。記憶部456を書き込み可能メモリとして形成することにより、高速割り込み処理であっても、その処理内容をある程度柔軟に設定できる。
{MP実装例}
According to the
{MP implementation example}
図46は、一般的なMPシステム500のハードウェア構成図である。
まず、図46、図47に関連して一般的なMPシステム500の構成とその問題点について説明し、その後、本MP実装例におけるタスク処理装置100について説明する。
FIG. 46 is a hardware configuration diagram of a
First, the configuration and problems of a
一般的なMPシステム500においては、バス504を介して複数のCPU150a〜150c、メモリ502、割込回路506が互いに接続される。メモリ502にはソフトウェアMPRTOSのプログラムが保存される。CPU150はキャッシュやローカルメモリを内蔵する。いずれのCPU150も必要に応じてソフトウェアMPRTOSを内蔵キャッシュあるいは内蔵ローカルメモリにロードして実行する。図46、図47では、タスクレディリスト(図11参照)がCPU150ごとに複数用意され、ウェイトセマフォリスト等のウェイト系のリスト(図13参照)は全CPU150に対して唯一用意されるものとする。また、タスクはいずれかのCPU150に固定的に割り振られるものとする。たとえば、あるタスクTnはCPU150aのみで実行され、それ以外のCPUでは実行されない。
In a
図47は、メモリ502のデータ構造を模式的に示す図である。
メモリ502には、プログラム508とデータ510が記憶される。プログラム508には、ソフトウェアRTOS自身のプログラム(実行コード)512とタスク自身のプログラム(実行コード)514が含まれる。いずれもオブジェクトコードである。データ510には、ソフトウェアRTOSの管理下にあるRTOSデータ516、タスクに固有のタスクデータ518および全タスクに共通のグローバルデータ522が含まれる。TCBはRTOSデータ516の一種であり、タスクレディリストやウェイト系リストなどの各種リストもRTOSデータ516の一種である。すべてのタスクからアクセスされるグローバル変数は、グローバルデータ522として記憶される。各タスクに固有のデータ、たとえば、タスク(アプリケーション)のローカル変数等は、タスクデータ518として記憶される。
FIG. 47 is a diagram schematically showing the data structure of the
The
ソフトウェアMPRTOSは、CPUからメモリ502へのアクセスを排他制御する必要がある。たとえば、CPU1がウェイト系リストにアクセスするとき、CPU2からも同一のウェイト系リストへのアクセスが発生する可能性がある。ソフトウェアMPRTOSは、アトミック操作命令と呼ばれる特別な命令を使ってウェイト系リストへのアクセスを排他制御する。
The software MPRTOS needs to exclusively control access from the CPU to the
具体的には、CPU1がウェイト系リストへアクセスするとき、まず、CPU1のソフトウェアMPRTOSはCPU1への割り込みを禁止する。これにより、CPU1におけるアクセス中のタスクスイッチを禁止しておく。次に、CPU1のソフトウェアMPRTOSは、ウェイト系リストへのアクセス権を取得する(ロック)。アクセス権が得られなければCPU1は割り込み禁止されたまま待たされる。アクセスが完了すると、ウェイト系リストへのアクセス権はアンロックされ、最後に割り込み禁止も解除される。このように、アトミック操作命令には割り込み禁止とその解除、リソースのロックとアンロックという付加的な実行コスト(オーバーヘッド)が生じる。CPU1がアトミック操作命令を実行しているときには、CPU2はCPU1のアクセスが終了するまで待たされる。CPU1のアクセスが完了すると、CPU2は同様のアトミック操作命令によりウェイト系リストへアクセスする。MPシステム500のスループットを向上させるためには、アトミック操作命令にともなうオーバーヘッドを低減する必要がある。
Specifically, when the
CPUごとに用意されるタスクレディリストへのアクセス時にも排他制御が必要となる。たとえば、CPU1においてタスクT1が実行中であり、CPU2においてはタスクT2aが実行中でタスクT2bがWAIT状態にあるとする。ここで、タスクT1がリリースセマフォシステムコール等のSET系システムコール命令を実行した結果として、タスクT2bのWAIT解除条件が成立したとする。 Exclusive control is also required when accessing a task ready list prepared for each CPU. For example, it is assumed that task T1 is being executed in CPU1, task T2a is being executed in CPU2, and task T2b is in the WAIT state. Here, it is assumed that the WAIT cancellation condition for task T2b is satisfied as a result of task T1 executing a SET system call instruction such as a release semaphore system call.
リリースセマフォシステムコールの実行に際してはCPU1にはソフトウェアMPRTOSがロードされる。更に、CPU1のソフトウェアMPRTOSは共有リソースであるウェイトセマフォリストをチェックして、WAIT中のタスクT2bをWAIT状態からREADY状態に変更する。この状態変更のためには、CPU1のソフトウェアMPRTOSがCPU2用のタスクレディリストにもアクセスする必要がある。WAIT状態から解放されたタスクT2bのタスク優先順位がCPU2で現在実行中のタスクT2aのタスク優先順位よりも高ければ、CPU2においてもタスクスイッチが必要である。この場合、CPU1のソフトウェアMPRTOSはCPU2に割り込みをかける。CPU1からの割り込みによりCPU2にもソフトウェアMPRTOSがロードされ、タスクT2aからタスクT2bへのタスクスイッチが実行される。
以下、あるCPUにおけるシステムコール等の実行により、同一または別のCPUにおいてタスクスイッチが発生する事象を「ディスパッチ」とよぶ。CPU1におけるリリースセマフォシステムコールの実行によりCPU2においてタスクスイッチが発生しているため、上述の処理はディスパッチに該当する。
When executing the release semaphore system call, the
Hereinafter, an event in which a task switch occurs in the same or another CPU by executing a system call or the like in a certain CPU is referred to as “dispatch”. Since a task switch has occurred in
上述の例では、少なくとも、(A1)MPRTOS(CPU1)によるウェイトセマフォリストへのアクセス、(A2)MPRTOS(CPU1)によるCPU2のタスクレディリストへのアクセス、(A3)MPRTOS(CPU2)によるCPU2のタスクレディリストへのアクセスにともなう排他制御が必要である。ソフトウェアMPRTOSの場合、複数のCPUが複数のソフトウェアMPRTOSを同時実行することもあるため排他制御の実行コストは大きくなりやすい。 In the above example, at least (A1) MPRTOS (CPU1) accesses the wait semaphore list, (A2) MPRTOS (CPU1) accesses CPU2 task ready list, (A3) MPRTOS (CPU2) performs CPU2 task. Exclusive control with access to the ready list is required. In the case of software MPRTOS, the execution cost of exclusive control tends to increase because a plurality of CPUs may execute a plurality of software MPRTOSs simultaneously.
基本例等に示したタスク処理装置100(ハードウェアRTOS)によれば、一般的なソフトウェアRTOSに比べてタスクスイッチの実行コストを大きく削減できる。MP実装例では、更に、以下に示すハードウェア・ロジックを導入することにより、排他制御の実行コストを削減する。 According to the task processing apparatus 100 (hardware RTOS) shown in the basic example, the execution cost of the task switch can be greatly reduced as compared with a general software RTOS. In the MP implementation example, the execution cost of exclusive control is further reduced by introducing the following hardware logic.
図48は、MP実装例におけるタスク処理装置100の回路図である。
MP実装例におけるタスク制御回路200は、複数のCPU0、CPU1・・・CPUmと接続される。タスク制御回路200には、プロセッサ切換回路530およびプロセッサ管理レジスタ524が追加される。CPUと退避回路120は直接接続されるのではなく、プロセッサ切換回路530を介して接続される。
FIG. 48 is a circuit diagram of the
The
プロセッサ切換回路530からCPU0には、停止要求信号(HR0)、書き込み信号(WT0)および退避データが送信され、CPU0からプロセッサ切換回路530には、停止完了信号(HC0)、システムコール信号(SC0)および処理データが送信される。システムコール信号(SC0)は、基本例と同様、CPU0においてシステムコール命令が実行されたときにアサートされる。CPU0がシステムコール命令が実行すると、CPU0は自動的に停止する。CPUクロックを完全に停止(Stop)させてもよいし、CPUクロックの無効化等による処理の一時停止(Suspend)であってもよい。いずれにしても「CPUの停止」とは、CPUがタスク実行を続行しない状態であればよい。タスク制御回路200はシステムコール信号(SC0)がアサートされると停止要求信号(HR0)をアサートする。書き込み信号(WT0)がアサートされると、退避回路120から送出された退避データがCPU0の処理レジスタにロードされる。また、CPU0の処理データは、常時、プロセッサ切換回路530に出力されている。他のCPU1〜CPUmについても同様である。CPUとプロセッサ切換回路530の間の信号は、基本例におけるCPUとタスク切換回路210の間の信号と基本的には同じである。
A stop request signal (HR0), a write signal (WT0), and saved data are transmitted from the
プロセッサ切換回路530からタスク切換回路210には、システムコール信号(SC)、プロセッサ通知信号(SCP)、停止完了信号(HC)が送信され、タスク切換回路210からプロセッサ切換回路530には、システムコール確認信号(SCACK)、プロセッサ指定信号(HRP)、書き込み信号(WT)が送信される。
A system call signal (SC), a processor notification signal (SCP), and a stop completion signal (HC) are transmitted from the
CPU0がシステムコール信号(SC0)をアサートするとき、プロセッサ切換回路530はシステムコール信号(SC)とHR0信号をアサートし、CPUのIDであるプロセッサIDをプロセッサ通知信号(SCP)により送信する。プロセッサ切換回路530がシステムコール信号(SC)をアサートすると、タスク切換回路210はシステムコール確認信号(SCACK)をアサートする。MP実装例では、タスク切換回路210は、システムコール信号(SC)が送信されてから所定時間経過後にシステムコール処理等を実行可能と判断する。システムコール処理が完了すると、SCACK信号がネゲートされ、HR0信号もネゲートされる。CPU0はHR0信号のネゲートを契機として再開される。基本例では、システムコール命令の実行に際しては書き込み信号(WT)の立ち下がりを契機としてCPUクロックを再開(有効化)していたが、図48に示す構成ではSCACK信号およびHR0信号のネゲートを契機としてCPUクロックを再開(有効化)している。
When the
タスク制御回路200がCPU0を停止させることもある。このときには、タスク切換回路210は停止要求信号(HR)をアサートし、停止対象となるCPU0のプロセッサID(0)をプロセッサ通知信号(HRP)により送信する。プロセッサ切換回路530は、HR0信号をアサートし、CPU0を停止させる。CPU0が停止すると、HC0信号がアサートされ、更に、停止完了信号(HC)がアサートされる。HC信号のアサートにより、タスク切換回路210はCPU0の停止を認識し、タスクスイッチ等を実行可能と判断する。MP実装例におけるHC信号は、HR信号に対する応答専用である。
The
プロセッサ管理レジスタ524は、各CPUにおけるRUNタスクとそのタスク優先順位等を示すプロセッサ管理情報を保持する。プロセッサ管理情報の詳細については、図50に関連して後述する。
The
なお、本実施例においても、タスクはいずれかのCPUに固定的に対応づけられ、READYキュー(後述)はCPUごとに用意され、WAITキュー(後述)は全CPUで共通であるとして説明する。 In this embodiment as well, a task is fixedly associated with any CPU, a READY queue (described later) is prepared for each CPU, and a WAIT queue (described later) is common to all CPUs.
図49は、MPタスクIDのデータ構造図である。
MP実装例におけるタスクIDをMPタスクID(MEID)とよぶ。本実施例におけるMPタスクIDは7ビットであり、上位3ビットがプロセッサID(PID)、下位4ビットがタスクそのもののタスクID(EID)である。すなわち、CPUは最大8個、タスクは最大16個まで実装可能である。実装可能なCPU数やタスク数はPIDおよびEIDのサイズによって規定される。
FIG. 49 is a data structure diagram of the MP task ID.
The task ID in the MP implementation example is called an MP task ID (MEID). The MP task ID in this embodiment is 7 bits, the upper 3 bits are the processor ID (PID), and the lower 4 bits are the task ID (EID) of the task itself. That is, a maximum of 8 CPUs and a maximum of 16 tasks can be mounted. The number of CPUs and tasks that can be mounted are defined by the sizes of PID and EID.
図50は、プロセッサ管理情報のデータ構造図である。
プロセッサ管理レジスタ524は、プロセッサ管理情報を含む。プロセッサ管理情報においては、各CPUで実行されているタスク(RUN−タスク)とタスク優先順位、種別が登録される。図50によれば、プロセッサID=0のCPU0では、タスク(E4)が実行中であり、タスク優先順位PRは0、種別は一般タスク(N)である。CPU2では、特別タスク(S)であるタスク(E15)が実行中である。タスク切換回路210は、プロセッサ管理レジスタ524にアクセスすることで、全CPUにおいて実行中のタスクをリアルタイム監視できる。いいかえれば、ソフトウェアではなくハードウェアのレベルで、全RUN−タスクが認識される。なお、プロセッサ管理情報の一部または全部は、プロセッサ管理レジスタ524ではなく状態記憶部220に記憶されてもよい。
FIG. 50 is a data structure diagram of processor management information.
The
図51は、MP実装例におけるREADYキューの概念図である。
READY状態に対応する仮想キュー(以下、「READYキュー」とよぶ)は、CPUごとに用意される。仮想キュー(QR0)は、CPU0のREADYキューである。図50に示したように、CPU0、CPU1、CPUmではそれぞれタスク(E4)、タスク(E9)、タスク(E2)が実行中である。また、CPU0のREADYキュー(QR0:0)にはタスク(E1)が投入されている。
FIG. 51 is a conceptual diagram of the READY queue in the MP implementation example.
A virtual queue corresponding to the READY state (hereinafter referred to as “READY queue”) is prepared for each CPU. The virtual queue (QR0) is a READY queue of CPU0. As shown in FIG. 50, task (E4), task (E9), and task (E2) are being executed in CPU0, CPU1, and CPUm, respectively. The task (E1) is put in the READY queue (QR0: 0) of the CPU0.
図52は、MP実装例におけるWAITキューの概念図である。
WAIT状態に対応する仮想キュー(以下、「WAITキュー」とよぶ)は、全CPUで共通に用意される。仮想キュー(QWa)はセマフォaを対象としたWAITキューであり、仮想キュー(QWb)はセマフォbを対象としたWAITキューである。図52では、WAITキュー(QWa:0)にはタスク(E3)が投入されており、WAITキュー(QWb:0)とWAITキュー(QWb:1)にはそれぞれタスク(E8)とタスク(E7)が投入されている。図53は、図51、図52に対応した状態レジスタのデータ構造図である。RUN−タスク(E2)は、仮想キューにないため「Non」が設定されている。MP実装例では、仮想キュー実装例と同様、仮想キューごとに順序値を設定している。変形例として、すべての仮想キューに対して通し番号となる唯一の順序値を設定してもよい。図51の例では、仮想キュー(QR0)にはタスク(E1)、仮想キュー(QR1)にはタスク(E0)、仮想キュー(QRm)にはタスク(E5)、タスク(E6)が投入されている。タスク(E1)、タスク(E5)、タスク(E0)、タスク(E6)の順に投入されているのであれば、通し番号方式の場合にはそれぞれの順序値を3,2,1,0とすればよい。
FIG. 52 is a conceptual diagram of the WAIT queue in the MP implementation example.
A virtual queue corresponding to the WAIT state (hereinafter referred to as “WAIT queue”) is prepared in common for all CPUs. The virtual queue (QWa) is a WAIT queue for semaphore a, and the virtual queue (QWb) is a WAIT queue for semaphore b. In FIG. 52, the task (E3) is input to the WAIT queue (QWa: 0), and the task (E8) and the task (E7) are respectively stored in the WAIT queue (QWb: 0) and the WAIT queue (QWb: 1). Has been introduced. FIG. 53 is a data structure diagram of the status register corresponding to FIGS. 51 and 52. Since the RUN-task (E2) is not in the virtual queue, “Non” is set. In the MP implementation example, an order value is set for each virtual queue as in the virtual queue implementation example. As a modification, a unique sequence value that is a serial number may be set for all virtual queues. In the example of FIG. 51, the task (E1) is input to the virtual queue (QR0), the task (E0) is input to the virtual queue (QR1), and the task (E5) and the task (E6) are input to the virtual queue (QRm). Yes. If task (E1), task (E5), task (E0), and task (E6) are entered in this order, if the serial number method is used, the respective order values are 3, 2, 1, and 0. Good.
MP実装例においては、MPタスクID(MEID)にタスクID(EID)に加えてプロセッサID(PID)が含まれている。これに対応して図32に示したタスク選択回路230の構成が一部変更される。タスク選択回路230は、メイン回路400からの問い合わせを受けたときに抽出タスク(たとえば、次のRUN−タスク)を特定する。仮想キュー実装例においては、RUN−タスクを選択する上での第1条件は「READY−タスクであること」であるが、MP実装例では更に「指定されたプロセッサID(PID)を有すること」という条件が追加される。本MP実装例では、タスクはCPUに固定的に割り当てられる。このため、CPU1でタスクスイッチを実行するときには、CPU1のPIDを含むタスクのみがRUN−タスクの候補となるため、判定回路434にPIDをチェックするためのロジックを追加すればよい。具体的には、状態記憶部220から供給されるPIDと、メイン回路400から供給されるQIDによって指定されるPIDが一致しなければ、判定回路434はEID_XX_EN信号をアサートしない、とすればよい。図28に示した最大値選択回路406等についても同様であり、PIDの追加だけなので実質的な回路変更はほとんど生じない。
In the MP implementation example, the MP task ID (MEID) includes a processor ID (PID) in addition to the task ID (EID). Correspondingly, the configuration of the
次に、MPシステム500に対応するタスク処理装置100のシステムコール処理およびインタセプト処理について説明する。
[システムコール実行]
Next, system call processing and intercept processing of the
[Execute system call]
図51等を参照しつつ、CPU0のタスク(E4)がシステムコール命令を実行し、タスク(E4)からタスク(E1)へのタスクスイッチが発生するとして説明する。
S1.タスク(E4)がシステムコール命令を実行し、SC0信号がアサートされる。CPU0は自動停止する。
S2.プロセッサ切換回路530は、HR0信号をアサートする。ただし、すでにCPU0は停止しているのでHR0信号のアサートによってCPU0の状態が変化することはない。HR0信号をアサートするのは、後にHR0信号のネゲートタイミングをCPU0に認識させるためである(後述)。
S3.プロセッサ切換回路530は、SC信号もアサートし、かつ、SCP信号においてプロセッサID=0を指定する。
S4.タスク切換回路210は、SCACK信号をアサートする。SCACKのアサートされると、プロセッサ切換回路530はシステムコール処理の開始を認識し、SCACKがネゲートされるまで待機する。プロセッサ切換回路530は、退避回路120とCPU0を接続する。
S5.タスク制御回路200は、基本例と同様のプロセスにより、システムコール処理を実行する。CPU0でのタスクスイッチが発生するときには、WT信号がアサートされ、タスク(E4)の処理データとタスク(E1)の退避データが入れ替えられる。システムコール処理が完了すると、タスク切換回路210はSCACK信号をネゲートする。タスク切換回路210は、タスク(E1)をCPU0の新たなRUN−タスクとしてプロセッサ管理レジスタ524に登録する。
S6.プロセッサ切換回路530は、SCACK信号のネゲートに反応してHR0信号をネゲートする。CPU0は、HR0信号のネゲートを契機として再開し、タスク(E1)が実行される。
[インタセプト処理]
With reference to FIG. 51 and the like, it will be described that the task (E4) of the
S1. Task (E4) executes the system call instruction, and the SC0 signal is asserted. CPU0 automatically stops.
S2. The
S3. The
S4. The
S5. The
S6. The
[Intercept processing]
タスク制御回路200からCPUの処理に積極的に割り込んでタスクスイッチを発生させることを「インタセプト」とよぶ。インタセプトは、タイムアウト、割り込み、システムコールの実行等を契機として発生する。たとえば、WAIT−タスクT3がタイムアウトしてすぐにRUN−タスクとなる場合には、タスク制御回路200はタイムアウトを検出してCPUを停止し、タスクスイッチを実行する。
Proactively interrupting the CPU processing from the
まず、WAIT状態にあるタスク(E3)がタイムアウトした場合について説明する。タスク(E3)はCPU2で実行されるタスクであるとする(PID=2)。
S1.タスク選択回路230がタスク(E3)のタイムアウトを検出する。
S2.タスク制御回路200は、基本例と同様のプロセスにより、タイムアウト処理を実行する。タスク(E3)がRUN−タスクとならないときには、すなわち、タスクスイッチ不要であれば、タスク(E3)はCPU2のREADYキューに投入され、タイムアウト処理は完了する。タスクスイッチが必要であれば、S3以降に進む。
S3.タスク切換回路210は、HR信号をアサートし、HRP信号によりCPU2を指定する。
S4.プロセッサ切換回路530は、HR2信号をアサートし、CPU2を停止させる。
S5.CPU2は、HC2信号をアサートする。
S6.プロセッサ切換回路530は、HC信号をアサートする。プロセッサ切換回路530は、処理データを退避レジスタ110に退避させ、退避データを処理レジスタ154にロードしてタスクスイッチさせる。
S7.CPU2のタスクスイッチ完了後、タスク切換回路210はHR信号をネゲートする。
S8.プロセッサ切換回路530は、HR2信号をネゲートする。CPU2のCPUクロックが再開され、タスク(E3)が実行される。
First, a case where the task (E3) in the WAIT state times out will be described. It is assumed that the task (E3) is a task executed by the CPU 2 (PID = 2).
S1. The
S2. The
S3. The
S4. The
S5. CPU2 asserts the HC2 signal.
S6. The
S7. After the task switching of the
S8. The
割り込み処理における処理過程もタイムアウト処理のそれと基本的に同様である。
高速割込要求信号INTR(H)における処理過程は、HW割込実装例で示した処理と同様である。通常割込要求信号INTR(N)のときには特殊タスクを起動する必要がある。すなわち、通常割り込み処理は必ずインタセプト(タスクスイッチ)をともなう。タスク制御回路200は割り込み先のCPUを停止させ、特殊タスクへのタスクスイッチを実行することになる。特殊タスクを実行するCPUは、固定されてもよいし、所定のルールにしたがって選択されてもよい。
The process in the interrupt process is basically the same as that in the timeout process.
The process in the high-speed interrupt request signal INTR (H) is the same as the process shown in the HW interrupt implementation example. When the normal interrupt request signal INTR (N) is received, it is necessary to activate a special task. That is, normal interrupt processing always involves an intercept (task switch). The
高速割り込み処理でもインタセプトが発生することがある。高速割り込み処理にともなってタスクスイッチが発生するときには、同様にして、タスク制御回路200は割り込み先のCPUを停止させ、タスクスイッチを実行する。HW割込実装例(SPシステム)では、高速割り込み処理に際してISR_RQ信号をアサートし、CPUを停止している。しかし、インタセプト(タスクスイッチ)をともなわない高速割り込み処理ではCPUを停止させる必要がないので、CPUを停止させずに高速割り込み処理を実行できる。このような処理方法によれば、CPUによるタスク実行とタスク制御回路200による高速割り込み処理を完全に並列実行できるため、いっそう効率的である。具体的には、タスク切換回路210は、高速割込要求信号INTR(H)が検出されたときでもタスクスイッチ不要と判断したときには、HR信号をアサートしなければよい。高速割込要求信号INTR(H)が頻発するタイプのアプリケーション・ソフトウェアではCPUを停止させずに高速割り込み処理を同時実行できるメリットは特に大きい。
[システムコールの競合]
Interception may occur even in high-speed interrupt processing. When a task switch occurs with high-speed interrupt processing, similarly, the
[System call conflict]
CPU0のタスク(E4)がシステムコール命令を実行し、その直後にCPU1のタスク(E9)もシステムコール命令を実行したとする。CPU0とCPU1はどちらも停止する。また、SC0信号とSC1信号が送信される。プロセッサ切換回路530は、まずは、SC0信号に対応し、SCP信号でCPU0を指定した上でSC信号をアサートする。タスク切換回路210はCPU0のシステムコール処理を実行する。また、プロセッサ切換回路530は、HR0信号とHR1信号の両方をアサートするが、CPU1のシステムコール信号(SC1)はプロセッサ切換回路530によって保留される。CPU0のシステムコール処理が終了するとSCACK信号がネゲートされ、HR0信号もネゲートされ、CPU0は再開する。次に、プロセッサ切換回路530は、SC1信号に対応し、SCP信号でCPU1を指定した上で再度SC信号をアサートする。保留されていたCPU1のシステムコール処理はCPU0のシステムコール処理の次に実行される。
It is assumed that the task (E4) of the
このように、複数のシステムコール命令は、プロセッサ切換回路530によってシリアライズされる。タスク(E4)とタスク(E9)がまったく同時にシステムコール信号を送信してきたときでも、プロセッサ切換回路530は、ランダム、ラウンドロビン等の任意のルールによってシステムコール処理の実行順を決定すればよい。プロセッサ切換回路530が複数のCPUからのシステムコール命令を一元的に受け付けてシリアライズするため、セマフォテーブル212や状態記憶部220等の共有リソースへの同時アクセスは論理的に発生し得ない。タスク処理装置100によるハードウェアMPRTOSでは、READYキュー等の共有リソースへのアクセスに際して、割込禁止と解除、リソースのロックとアンロックは不要となる。
[システムコールとインタセプトの競合]
As described above, the plurality of system call instructions are serialized by the
[System call and intercept conflict]
CPU0のタスク(E4)がシステムコール命令を実行し、その直後または同時に別のCPU1を対象としたインタセプトが発生したとする。この場合には、インタセプトが優先される。プロセッサ切換回路530は、CPU0を停止させ、システムコール信号(SC0)を保留しておく。インタセプト処理が終了すると、プロセッサ切換回路530は保留していたCPU0のシステムコール処理を実行する。CPU0のシステムコール信号を保留している最中に別のCPUへのインタセプトが発生した場合も、インタセプト処理が優先される。
Assume that the task (E4) of the
一方、CPU0のタスク(E4)がシステムコール命令を実行し、その直後または同時に同じCPU0を対象としたインタセプトが発生した場合には、システムコール処理が優先され、インタセプトは保留される。まず、システムコール命令の実行にともない、CPU0は停止し、HR信号、HR0信号がアサートされる。システムコール処理が完了し、SCACK信号がネゲートされると、プロセッサ切換回路530はHR信号、HR0信号をいったんネゲートする。これにより、CPU0は再開する。次に、インタセプトに対応して、HR信号、HR0信号が再びアサートされ、CPU0は再停止する。こうして、インタセプト処理が実行される。
On the other hand, when the task (E4) of the
図54は、ディスパッチにおける仮想キューとタスクの関係を示す概念図である。
ここでは、CPU0のタスク(E4)がシステムコール命令を実行した結果、CPU1でタスクスイッチが発生する場合について説明する。WAITキュー(QWb:0)のタスク(E8)は、CPU1で実行されるべきタスクであるとする。
FIG. 54 is a conceptual diagram showing the relationship between virtual queues and tasks in dispatch.
Here, a case where a task switch occurs in
S1.CPU0のRUN−タスク(E4)が、リリースセマフォシステムコールを実行したとする。図50に示したように、RUN−タスク(E4)のタスク優先度PRは0である。READY−タスク(E1)もタスク優先度PRが0なので、システムコール実行後もタスク(E4)はRUN−タスクのままである。すなわち、タスクスイッチは発生せず、プロセッサ管理レジスタ524は更新されない。
S2.リリースセマフォシステムコールの実行により、WAITキュー(QWb:0)にあったWAIT−タスク(E8)が抽出される。このとき、タスク切換回路210はプロセッサ管理レジスタ524を参照し、CPU1のRUN−タスク(E9)とWAIT−タスク(E8)のタスク優先順位を比較する。WAIT−タスク(E8)のタスク優先順位がRUN−タスク(E9)のタスク優先順位よりも高いので、タスク切換回路210はCPU1を対象としてタスクスイッチを実行する。具体的には、CPU1を指定してHR信号をアサートし、CPU1を停止させる。
WAIT−タスク(E8)のタスク優先順位がRUN−タスク(E9)のタスク優先順位以下のときには、WAIT−タスク(E8)をCPU1のREADYキュー(QR1:0)に投入するだけなのでタスクスイッチ(ディスパッチ)は不要である。
S3.CPU1の停止後、RUN−タスク(E9)は、READYキュー(QR1:2)に投入される。READY−タスク(E9)の処理データは処理レジスタ92から退避レジスタ110に退避される。
S4.WAIT−タスク(E8)が新たなRUN−タスクとなる。プロセッサ管理レジスタ524も更新される。タスク(E8)の処理データは退避レジスタ110から処理レジスタ92にロードされる。
S1. It is assumed that the RUN-task (E4) of CPU0 executes a release semaphore system call. As shown in FIG. 50, the task priority PR of the RUN-task (E4) is zero. Since the task priority PR of the READY-task (E1) is also 0, the task (E4) remains a RUN-task even after the system call is executed. That is, no task switch occurs and the
S2. By executing the release semaphore system call, the WAIT-task (E8) in the WAIT queue (QWb: 0) is extracted. At this time, the
When the task priority of the WAIT-task (E8) is equal to or lower than the task priority of the RUN-task (E9), the task switch (dispatch) is simply performed by putting the WAIT-task (E8) into the
S3. After the
S4. The WAIT-task (E8) becomes a new RUN-task. The
ディスパッチは、たとえば、リリースセマフォシステムコールやセットフラグシステムコール等のSET系システムコールによって、いずれかのCPUのタスクがWAIT状態からRUN状態に移行するときに発生する。そのほか、起動システムコールや終了システムコールにより別のCPUのタスクを強制的にRUNあるいはSTOPさせる場合にもディスパッチが発生する。 Dispatch occurs when a task of any CPU shifts from a WAIT state to a RUN state by, for example, a SET system call such as a release semaphore system call or a set flag system call. In addition, dispatch occurs when another CPU task is forcibly RUN or STOP by an activation system call or an end system call.
図55は、タスク切換回路532にプロセッサ切換回路530の機能を取り込んだ場合のタスク処理装置100の回路図である。
タスク切換回路532にプロセッサ切換回路530の機能を取り込んでもよい。退避回路120に含まれる第1ロード選択回路526は図48のロード選択回路112と同じである。図55では、新たに第2ロード選択回路528が追加されている。
FIG. 55 is a circuit diagram of the
The
図55に示すタスク制御回路200は、SC0〜SCm信号のいずれか、INTR信号またはタイムアウト信号がアサートされたときに作動する。タスク切換回路532は、第2ロード選択回路528にPID信号を送信する。PID信号により制御対象となるCPUが指定される。第2ロード選択回路528は、PID信号により指定されたCPUと退避回路120を接続する。プロセッサ切換回路530の機能のうち、複数のCPUのいずれかと退避回路120を接続する機能は第2ロード選択回路528により実現され、その他の機能はタスク切換回路532により実現される。
The
本MP実装例では、タスクとCPUの関係が固定されているとして説明したが、タスクID(EID)とプロセッサID(PID)は別々に取り扱われてもよい。たとえば、起動システムコールの実行に際して、タスクIDとプロセッサIDを指定することにより、MEIDに任意のPIDを設定してもよい。また、あるCPUから別のCPUにタスクを移動させるマイグレーションシステムコール命令を導入してもよい。このマイグレーションシステムコール命令の実行に際して、タスクIDと移動先CPUのプロセッサIDを指定することにより、MEIDのプロセッサIDを変更してもよい。すべてのタスクの実行状態は状態記憶部220とプロセッサ管理レジスタ524により管理されるため、状態記憶部220やプロセッサ管理レジスタ524のデータを書き換えるだけでタスクのマイグレーションを実現できる。
In the present MP implementation example, the relationship between the task and the CPU has been described as fixed, but the task ID (EID) and the processor ID (PID) may be handled separately. For example, when executing an activation system call, an arbitrary PID may be set in MEID by specifying a task ID and a processor ID. Also, a migration system call instruction for moving a task from one CPU to another CPU may be introduced. When executing this migration system call instruction, the processor ID of the MEID may be changed by specifying the task ID and the processor ID of the destination CPU. Since the execution states of all tasks are managed by the
たとえば、図51において、CPU0のREADY−タスク(E1)をCPU1のREDY−タスクに変更するときには、タスク(E1)のMEIDにCPU1のプロセッサIDを設定した上で、仮想キュー(QR1:0)へ順投入すればよい。このように仮想キューの設定、いいかえれば、状態記憶部220の書き換えだけでマイグレーションを実現できるため、マイグレーションシステムコール命令の実行コストもほとんど発生しない。
For example, in FIG. 51, when the READY-task (E1) of CPU0 is changed to the READY-task of CPU1, the processor ID of CPU1 is set in the MEID of task (E1) and the virtual queue (QR1: 0) is set. You can put them in order. Thus, since the migration can be realized only by setting the virtual queue, in other words, only rewriting the
以上、MPシステム500に対応可能なタスク処理装置100について説明した。
タスク処理装置100は、タスクスイッチだけでなく排他制御にともなう実行コストを大きく削減できる。一般例におけるソフトウェアMPRTOSは各CPUに適宜ロードされる。CPU1にロードされるソフトウェアMPRTOSが別のCPU2の実行状態を知るためにはアトミック操作命令を使ってメモリ502にアクセスしなければならない。メモリ502のリソースは常に競合的に利用されているため、その調整のための実行コストが大きくなりやすい。具体的には、割り込みの禁止と解除やリソースのロックとアンロックというオーバーヘッドが無視できないほど大きくなりやすい。
Heretofore, the
The
MP実装例においては、タスク制御回路200がREADYキューやWAITキューなどの多くの共有リソースを管理下に置いている。更に、タスク制御回路200はプロセッサ管理情報により全RUN−タスクの実行状況をリアルタイムかつハードウェアレベルで認識できる。この結果、タスク制御回路200が全CPUと全タスクの状態データを統括的に管理できる。タスク制御回路200が管理するリソースへのアクセスは、プロセッサ切換回路530によりシリアライズされるため割り込み禁止とその解除、リソースのロックとアンロックといった排他制御用の追加処理は不要となる。タスク制御回路200は、各種のインタセプトを自律的に発生させるが、インタセプトもシステムコールと同様にシリアライズされる。
In the MP implementation example, the
また、複数のCPUによるタスクの同時実行が可能であるだけでなく、インタセプトをともなわない高速割り込み処理をCPUを停止させることなく実行できる。すなわち、高速割り込み処理がタスク実行を中断させないため、いっそうの高速化が可能となっている。 Further, not only can tasks be simultaneously executed by a plurality of CPUs, but also high-speed interrupt processing without interception can be executed without stopping the CPU. In other words, since high-speed interrupt processing does not interrupt task execution, it is possible to further increase the speed.
READYキューやWAITキューなどの状態管理をタスク制御回路200がハードウェア・ロジックで実現するため、システムコール処理やインタセプト処理の実行コスト自体がソフトウェアRTOSよりも小さくなっている。ディスパッチについても同様である。タスクスイッチおよび排他制御にともなう実行コストが削減される結果、ソフトウェアRTOSによるマルチプロセッサ制御に比べて消費電力も抑制される。
なお、本実施例においてはCPUを制御対象として説明したが、DSP(Digital Signal Processor)など他のプロセッサについても応用可能である。
Since the
In this embodiment, the CPU has been described as a control target. However, the present invention can also be applied to other processors such as a DSP (Digital Signal Processor).
本実施例においては、タスク制御回路200はWT信号やHRP信号等により、処理データをロードおよび退避させている。基本例(SPシステム)では、タスク制御回路200がWT信号やTS信号等をアサートすることで、処理データのロードと退避を実行している。MP実装例では、タスク切換回路210がWT信号をアサートし、HRP信号にて対象となるCPUを指定することにより、プロセッサ切換回路530が処理データのロードおよび退避を実行している。
ただし、「タスク制御回路200による処理データの退避およびロード」は、タスク制御回路200が処理データを直接的に操作する場合に限定されない。たとえば、タスク制御回路200がタスクスイッチ指示命令を外部のレジスタ等に書き込み、CPU150上で実行される監視ソフトウェアがこのレジスタの書き込みを検出して処理データのロードおよび退避を実行してもよい。このような構成の場合、CPU150においてタスクスイッチ実行用のソフトウェアを実行する必要があるため、完全なハードウェアRTOSではなくなる。それでも一般的なソフトウェアRTOSに比べれば格段に実行コストは小さくて済む。
In the present embodiment, the
However, “saving and loading processing data by the
以上、本発明を実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。 In the above, this invention was demonstrated based on the Example. The embodiments are exemplifications, and it will be understood by those skilled in the art that various modifications can be made to combinations of the respective constituent elements and processing processes, and such modifications are within the scope of the present invention. .
Claims (9)
前記プロセッサは、システムコール命令を実行するとき、システムコール信号を前記タスク制御回路に送信し、
前記タスク制御回路は、第1のプロセッサから第1のシステムコール信号を受信したとき、プロセッサのプロセッサIDとそのプロセッサで実行中のタスクのタスクIDを登録されているプロセッサ管理情報を参照することにより前記第1のプロセッサにおいて実行中の第1のタスクを特定し、次に実行対象となる第2のタスクを自律的に選択し、前記第1のタスクの処理データを前記第1のプロセッサの処理レジスタから所定の記憶領域に退避させ、前記第2のタスクの処理データを前記第1のプロセッサの前記処理レジスタにロードさせ、前記プロセッサ管理情報を更新することにより、前記第1のプロセッサのタスクスイッチを実行し、かつ、
前記タスク制御回路は、前記第1のタスクの実行中に、前記第1のプロセッサを対象とした割込事象が発生したときであっても、前記第1のタスクの実行権の変更が発生しないときには、前記第1のタスクの実行を継続したまま前記割込事象に対応する処理を実行することを特徴とするタスク処理装置。 A task control circuit for managing execution states of a plurality of tasks executed by a plurality of processors;
When the processor executes a system call instruction, it sends a system call signal to the task control circuit,
When the task control circuit receives the first system call signal from the first processor, the task control circuit refers to the processor management information in which the processor ID of the processor and the task ID of the task being executed by the processor are registered. The first task being executed in the first processor is specified, the second task to be executed next is autonomously selected, and the processing data of the first task is processed by the first processor. The task switch of the first processor is saved from the register to a predetermined storage area, the processing data of the second task is loaded into the processing register of the first processor, and the processor management information is updated. And
The task control circuit does not change the execution right of the first task even when an interrupt event for the first processor occurs during the execution of the first task. In some cases, the task processing apparatus executes processing corresponding to the interrupt event while continuing execution of the first task.
前記プロセッサは、システムコール命令を実行するとき、システムコール信号を前記タスク制御回路に送信し、
前記タスク制御回路は、第1のプロセッサから第1のシステムコール信号を受信したとき、プロセッサのプロセッサIDとそのプロセッサで実行中のタスクのタスクIDを登録されているプロセッサ管理情報を参照することにより前記第1のプロセッサにおいて実行中の第1のタスクを特定し、次に実行対象となる第2のタスクを自律的に選択し、前記第1のタスクの処理データを前記第1のプロセッサの処理レジスタから所定の記憶領域に退避させ、前記第2のタスクの処理データを前記第1のプロセッサの前記処理レジスタにロードさせ、前記プロセッサ管理情報を更新することにより、前記第1のプロセッサのタスクスイッチを実行し、かつ、
前記タスク制御回路は、前記第1のプロセッサにおけるタスクスイッチが完了する前に第2のプロセッサが第2のシステムコール信号を送信したときには前記第2のシステムコール信号を保留し、前記第1のプロセッサのタスクスイッチに続いて前記第2のプロセッサのタスクスイッチを実行し、かつ、
前記タスク制御回路は、前記第1のタスクの実行中に、前記第1のプロセッサを対象とした割込事象が発生したときであっても、前記第1のタスクの実行権の変更が発生しないときには、前記第1のタスクの実行を継続したまま前記割込事象に対応する処理を実行することを特徴とするタスク処理装置。 A task control circuit for managing execution states of a plurality of tasks executed by a plurality of processors;
When the processor executes a system call instruction, it sends a system call signal to the task control circuit,
When the task control circuit receives the first system call signal from the first processor, the task control circuit refers to the processor management information in which the processor ID of the processor and the task ID of the task being executed by the processor are registered. The first task being executed in the first processor is specified, the second task to be executed next is autonomously selected, and the processing data of the first task is processed by the first processor. The task switch of the first processor is saved from the register to a predetermined storage area, the processing data of the second task is loaded into the processing register of the first processor, and the processor management information is updated. And
The task control circuit suspends the second system call signal when the second processor transmits a second system call signal before the task switch in the first processor is completed, and the first processor Executing a task switch of the second processor following the task switch of:
The task control circuit does not change the execution right of the first task even when an interrupt event for the first processor occurs during the execution of the first task. In some cases, the task processing apparatus executes processing corresponding to the interrupt event while continuing execution of the first task.
タスクと前記タスクの実行主体となるプロセッサのプロセッサIDを対応づけて保持する状態レジスタ、を備え、
前記プロセッサは、システムコール命令を実行するとき、システムコール信号を前記タスク制御回路に送信し、
前記タスク制御回路は、第1のプロセッサから第1のシステムコール信号を受信したとき、プロセッサのプロセッサIDとそのプロセッサで実行中のタスクのタスクIDを登録されているプロセッサ管理情報を参照することにより前記第1のプロセッサにおいて実行中の第1のタスクを特定し、前記状態レジスタを参照して、前記第1のプロセッサが実行主体となるタスクの中から次に実行対象となる第2のタスクを自律的に選択し、前記第1のタスクの処理データを前記第1のプロセッサの処理レジスタから所定の記憶領域に退避させ、前記第2のタスクの処理データを前記第1のプロセッサの前記処理レジスタにロードさせ、前記プロセッサ管理情報を更新することにより、前記第1のプロセッサのタスクスイッチを実行することを特徴とするタスク処理装置。 A task control circuit for managing execution states of a plurality of tasks executed by a plurality of processors;
A state register that holds the task and the processor ID of the processor that is the execution subject of the task in association with each other,
When the processor executes a system call instruction, it sends a system call signal to the task control circuit,
When the task control circuit receives the first system call signal from the first processor, the task control circuit refers to the processor management information in which the processor ID of the processor and the task ID of the task being executed by the processor are registered. The first task being executed in the first processor is specified, and the second task to be executed next is selected from the tasks for which the first processor is the execution subject with reference to the status register. Autonomously selecting, saving the processing data of the first task from a processing register of the first processor to a predetermined storage area, and transferring the processing data of the second task to the processing register of the first processor And executing the task switch of the first processor by updating the processor management information. Task processing device that.
第1段の比較回路が、2以上のタスクの状態データを所定の選択条件により比較するとともにタスクが対応づけられるプロセッサIDを検査し、いずれかのタスクの状態データを第2段の比較回路に出力し、
第n(nは2以上の自然数)段の比較回路が、第(n−1)段に位置する複数の比較回路から出力された状態データを前記所定の選択条件により比較して、いずれかのタスクの状態データを出力することにより、
最後段の比較回路により特定されたタスクを実行対象として選択することを特徴とする請求項4に記載のタスク処理装置。 The task control circuit includes a comparison circuit connected in multiple stages,
The comparison circuit in the first stage compares the state data of two or more tasks according to a predetermined selection condition, checks the processor ID to which the task is associated, and sets the state data of any task to the comparison circuit in the second stage Output,
An n-th (n is a natural number greater than or equal to 2) stage comparison circuit compares state data output from a plurality of comparison circuits located in the (n−1) -th stage according to the predetermined selection condition, and By outputting task status data,
The task processing apparatus according to claim 4, wherein the task specified by the last-stage comparison circuit is selected as an execution target.
前記プロセッサは、システムコール命令を実行するとき、システムコール信号を前記タスク制御回路に送信し、
前記タスク制御回路は、第1のプロセッサから第1のシステムコール信号を受信したとき、プロセッサのプロセッサIDとそのプロセッサで実行中のタスクのタスクIDを登録されているプロセッサ管理情報を参照することにより前記第1のプロセッサにおいて実行中の第1のタスクを特定し、次に実行対象となる第2のタスクを自律的に選択し、前記第1のタスクの処理データを前記第1のプロセッサの処理レジスタから所定の記憶領域に退避させ、前記第2のタスクの処理データを前記第1のプロセッサの前記処理レジスタにロードさせ、前記プロセッサ管理情報を更新することにより、前記第1のプロセッサのタスクスイッチを実行し、かつ、
前記タスク制御回路は、前記第1のプロセッサにおけるタスクスイッチが完了する前に第2のプロセッサが第2のシステムコール信号を送信したときには前記第2のシステムコール信号を保留し、前記第1のプロセッサのタスクスイッチに続いて前記第2のプロセッサのタスクスイッチを実行することを特徴とするタスク処理装置。 A task control circuit for managing execution states of a plurality of tasks executed by a plurality of processors;
When the processor executes a system call instruction, it sends a system call signal to the task control circuit,
When the task control circuit receives the first system call signal from the first processor, the task control circuit refers to the processor management information in which the processor ID of the processor and the task ID of the task being executed by the processor are registered. The first task being executed in the first processor is specified, the second task to be executed next is autonomously selected, and the processing data of the first task is processed by the first processor. The task switch of the first processor is saved from the register to a predetermined storage area, the processing data of the second task is loaded into the processing register of the first processor, and the processor management information is updated. And
The task control circuit suspends the second system call signal when the second processor transmits a second system call signal before the task switch in the first processor is completed, and the first processor A task processing apparatus for executing a task switch of the second processor subsequent to the task switch.
前記プロセッサは、システムコール命令を実行するとき、システムコール信号を前記タスク制御回路に送信し、
前記タスク制御回路は、前記プロセッサから前記システムコール信号を受信したとき、実行中のタスクに対応する状態データをRUN(ラン)状態から他の状態に設定変更し、次に実行対象となるタスクを自律的に選択し、実行中のタスクの処理データを前記プロセッサの処理レジスタから所定の記憶領域に退避させ、前記選択したタスクの処理データを前記プロセッサの前記処理レジスタにロードするとともにそのタスクをRUN状態に変更することにより、前記プロセッサのタスクスイッチを実行し、かつ、
前記タスク制御回路は、タスクの実行中に割込事象が発生したときであっても、前記タスクの実行権の変更が発生しないときには、前記タスクの実行を継続したまま前記割込事象に対応する処理を実行することを特徴とするタスク処理装置。 A task control circuit for managing execution states of a plurality of tasks executed in the processor;
When the processor executes a system call instruction, it sends a system call signal to the task control circuit,
When the task control circuit receives the system call signal from the processor, the task control circuit changes the state data corresponding to the task being executed from the RUN state to another state, and the task to be executed next is changed. Autonomous selection, processing data of the task being executed is saved from the processing register of the processor to a predetermined storage area, processing data of the selected task is loaded into the processing register of the processor and the task is run Executing a task switch of the processor by changing to a state; and
The task control circuit responds to the interrupt event while continuing execution of the task even when an interrupt event occurs during the execution of the task and the task execution right does not change. A task processing device that executes processing.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017043612A JP2017123190A (en) | 2017-03-08 | 2017-03-08 | Task processing device |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017043612A JP2017123190A (en) | 2017-03-08 | 2017-03-08 | Task processing device |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014516588A Division JP6153925B2 (en) | 2012-05-24 | 2012-05-24 | Task processing device |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2018195064A Division JP2019003710A (en) | 2018-10-16 | 2018-10-16 | Task processing device |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2017123190A true JP2017123190A (en) | 2017-07-13 |
Family
ID=59306665
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017043612A Pending JP2017123190A (en) | 2017-03-08 | 2017-03-08 | Task processing device |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2017123190A (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020086871A (en) * | 2018-11-22 | 2020-06-04 | Necプラットフォームズ株式会社 | Information processor, program, operating system, execution method, and program correction method |
CN111538579A (en) * | 2020-04-23 | 2020-08-14 | 山东华芯半导体有限公司 | Multitask operation method under embedded platform |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09305553A (en) * | 1996-05-15 | 1997-11-28 | Hitachi Ltd | Parallel computer system |
WO2009022371A1 (en) * | 2007-08-16 | 2009-02-19 | Netcleus Systems Corporation | Task processor |
WO2009090684A1 (en) * | 2008-01-15 | 2009-07-23 | Netcleus Systems Corporation | Task processor |
JP2010049700A (en) * | 2009-10-21 | 2010-03-04 | Net Kuriasu Systems Kk | Task processing apparatus |
JP2010140239A (en) * | 2008-12-11 | 2010-06-24 | Internatl Business Mach Corp <Ibm> | Apparatus and method for shortening interrupt latency |
-
2017
- 2017-03-08 JP JP2017043612A patent/JP2017123190A/en active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09305553A (en) * | 1996-05-15 | 1997-11-28 | Hitachi Ltd | Parallel computer system |
WO2009022371A1 (en) * | 2007-08-16 | 2009-02-19 | Netcleus Systems Corporation | Task processor |
WO2009090684A1 (en) * | 2008-01-15 | 2009-07-23 | Netcleus Systems Corporation | Task processor |
JP2010140239A (en) * | 2008-12-11 | 2010-06-24 | Internatl Business Mach Corp <Ibm> | Apparatus and method for shortening interrupt latency |
JP2010049700A (en) * | 2009-10-21 | 2010-03-04 | Net Kuriasu Systems Kk | Task processing apparatus |
Non-Patent Citations (3)
Title |
---|
JAEHWAN LEE, VINCENT JOHN MOONEY III, ANDERS DALEBY, KARL INGSTROM, TOMMY KLEVIN, LENNART LINDH: "A Comparison of the RTU Hardware RTOS with a Hardware/Software RTOS", ASP-DAC'03 PROCEEDINGS OF THE 2003 ASIA AND SOUTH PACIFIC DESIGN AUTOMATION CONFERENCE, JPN7012002361, 2003, US, pages 683 - 686 * |
戦略的基盤技術高度化支援事業研究開発成果事例集 平成21年度〜平成23年度採択事業, JPN6012032114, March 2012 (2012-03-01), JP, pages p.20−21 * |
高橋浩和、三好和人: "図解 Linuxカーネル2.4の設計と実装 第5回 マルチプロセッサ対応", LINUX JAPAN, vol. 第4巻,第3号(通巻27号), JPN6012032113, 1 March 2001 (2001-03-01), JP, pages p.170 * |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020086871A (en) * | 2018-11-22 | 2020-06-04 | Necプラットフォームズ株式会社 | Information processor, program, operating system, execution method, and program correction method |
CN111538579A (en) * | 2020-04-23 | 2020-08-14 | 山东华芯半导体有限公司 | Multitask operation method under embedded platform |
CN111538579B (en) * | 2020-04-23 | 2023-02-03 | 山东华芯半导体有限公司 | Multitask operation method under embedded platform |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6153925B2 (en) | Task processing device | |
JP4088335B1 (en) | Virtual queue processing circuit and task processing device | |
US10949249B2 (en) | Task processor | |
JP4119945B2 (en) | Task processing device | |
JP4127848B2 (en) | Task processing device | |
JP2018180768A (en) | Semiconductor device | |
JP5155336B2 (en) | Task processing device | |
JP2017123190A (en) | Task processing device | |
JP5204740B2 (en) | Task processing device | |
JP2019003710A (en) | Task processing device | |
JP2008269597A (en) | Task processor |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170405 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20171205 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180201 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20180717 |