プリエンプティブZ80アセンブラーマルチタスク

遅いプロセッサと少量のRAM-これは、そのようなプラットフォームでプリエンプティブマルチタスクを実装することが不可能であることを意味しません。 さらに、マルチタスク環境を編成する主な目的は、プロセッサ時間を効率的に使用することです。これにより、一部のプログラムがイベントを待機している間はプロセッサがアイドル状態にならず、他のプログラムによって使用されます。 ZX Spectrum（Z80 3.5MHz、48-128kBのRAM）、または8ビットAVRマイクロコントローラーのようなプラットフォームでも、プリエンプティブマルチタスクを編成することは非常に理にかなっています。



アセンブラーZ80（ZX Spectrum）でのマルチタスクディスパッチャーの独自の実装に注目してください。これは、OSの一部ではありませんが、個別に使用できます。 余分なものは何もありません-スレッドの実行とそれらの間の同期の組織だけです。 ディスパッチャは、ソフトウェアプロジェクトの不可欠な部分として、OS用のより深刻なディスパッチャを作成するための基礎として、またはトレーニング資料として使用できます。

実装されたマルチタスクシステムのアーキテクチャ

このアーキテクチャは、ReactOSソースを研究したときにWindows NTカーネルの概念に触発されました[2]。 これらの概念のうち、マルチタスクの必要な機能を提供する最小限のものが実装されました。 より完全な実装も可能ですが、ある時点から、追加の機能は小型コンピューターのコストのために正当化されなくなります。

スレッド

スレッド[1]は、ディスパッチャーによって制御される基本単位です。 各スレッドには実行可能コードと独自のスタックがあり、ルーチンやその他の情報からの戻りアドレスを保存するために使用できます。 ディスパッチャは、実行をあるスレッドから別のスレッドに切り替え、可能な場合、すべてのスレッドが必要なコードを実行するようにします。



各スレッドは、待機中（待機中）、実行準備完了（準備完了）、実行中（実行中）の3つの状態のいずれかになります。 アイドル状態では、スレッドが待機しているイベントが発生するまで、ディスパッチャはスレッドコードの実行を防止します。 準備完了状態のスレッドは、できるだけ早くコントローラーから制御を受け取ります。 システムにはプロセッサが1つしかないため、実行状態にできるスレッドは1つだけです。 そのコードは、スレッドがスタンバイ状態になるまで、またはプリエンプションが発生するまで、つまりディスパッチャが独自のイニシアチブで制御を別のスレッドに転送しないまで、プロセッサによって実行されます。



システム内のスレッドの数は固定されています。 新しいスレッドは開始せず、古いスレッドは終了しません。 マイクロコントローラーアプリケーションの場合、または別のアプリケーションの一部として、この制限は重要ではありません。 しかし、ディスパッチャーは単純化され、その作業は加速されます。



各スレッドには優先順位があります。 準備完了状態のスレッドが複数ある場合、ディスパッチャは優先度が最も高いスレッドの1つを実行することを選択します。 ディスパッチャの現在のバージョンでは、操作中にストリームの優先度を変更できません。 フローの動的優先度は実装するのにコストがかかりますが、優先度の逆転の問題を解決するにはこの機能が必要です[1]。



システム内のすべてのスレッドの優先順位は異なります。 これは、ディスパッチャが同じ優先度で擬似並列コード実行を編成せず、プロセッサをあるス​​レッドから別のスレッドにすばやく切り替えることを意味します（「ラウンドロビン」）。 しかし実際には、この制限は重要ではありません。 いくつかのスレッドを擬似並列実行すると、各スレッドの速度が低下します。 コンピュータメモリのリソースが限られていることを考えると、このようなプログラムの順次実行を整理する方が適切です。 プリエンプティブマルチタスクの主な利点は、擬似並列実行の可能性ではなく、重要なソース（ユーザーがキーボードのキーを押すことへの応答など）からの要求を処理する短期タスクと、完了時間が重要ではないプログラムの長い作業（コンパイル、アーカイブ）の間のプロセッサの効率的な分離です。 キーストロークを処理するストリームに高い優先度を割り当て、アーカイブストリームに低い優先度を割り当てると、テキストを編集するユーザーの観点からは、エディターの速度は低下しませんが、バックグラウンドでは、ファイルはボーナスとしてアーカイブされます。

待機オブジェクト（同期オブジェクト）

それらに基づいて、スレッドはディスパッチャの対応する関数を呼び出すことで待機状態になります。 スタンバイオブジェクトに信号が送られる場合と送られない場合があります。 シグナルが送信された場合、待機関数はすぐに戻り、スレッドは実行を継続します。 オブジェクトに信号が送られない場合、スレッドは待機状態になり、準備状態にある他のスレッドの実行が開始されます。 オブジェクトが通知されるとすぐに、待機中のスレッドは準備完了状態に戻り、できるだけ早くディスパッチャーから制御を受け取ります。 オペレーティングシステムには、通常、イベント、セマフォ、ミューテックスなどの待機オブジェクトがあります。このディスパッチャには、通知イベント（手動リセット）と同期イベント（自動リセット）の2種類のイベントが実装されています。 。

IRQL

プロセッサーの状態 Windows NTの略語は「割り込み要求レベル」[3]を表していますが、これは概念の意味を正確に反映していません。 説明したディスパッチャーには3つのIRQLレベルがあります。 PASSIVE_LEVEL-これは、プロセッサがスレッドの1つのコードを現在実行しているときです。 この時点で、実行可能スレッドが別のスレッドによって混み合っているか、プロセッサがハードウェア割り込みの処理を開始する場合があります。 DISPATCH_LEVEL-重要なディスパッチャコードの実行中、プロセッサはこの状態にあります。 たとえば、スレッド間の実行の切り替えは、多くのアクションで構成される操作です。 現時点では、プロセッサがこのスレッドまたはそのスレッドを実行しているとは言えません。まるで「それらの間」のようです。 この点で、DISPATCH_LEVELモードで実行されたコードを混雑させることはできません。 最後に、第3レベル-DIRQL-は、プロセッサが現在ハードウェア割り込みを処理しているという事実に対応しています。



Windows NTとは異なり、私のディスパッチャには、現在のIRQLレベルが保存される場所がありません。 また、明示的に増減する機能もありません。 しかし、概念としてのIRQLは、暗黙的にではありますが、システムに暗示され、客観的に存在します。



ユーザーコードは、スレッド（PASSIVE_LEVEL）またはDIRQLのユーザー割り込みルーチン（ISR）で実行できます。 使用可能なディスパッチャー関数のセットは、IRQLによって異なります。 IRQL要件に違反すると、システムがクラッシュします。



スレッドで実行されるユーザーコードは、割り込みを禁止するべきではありません。 ISRコードは禁止された割り込みで実行されるため、反対に許可されません。 DISPATCH_LEVELに関しては、Windows NTではこのモードで割り込みは禁止されていません。ディスパッチャでは、簡単にするためにDISPATCH_LEVELで割り込みが無効になっています。

ディスパッチャー関数

機能の目的とその機能の説明が記載されています。 これらの関数にパラメーターを渡す詳細は、ソースコードへのコメントに記載されており、テキストが乱雑にならないようにここでは複製されません。 可能であれば、関数の名前はWindows NTカーネルの類似の関数の名前と同じです[2,3]。

KeResetEvent

イベントタイプの待機オブジェクトのアラームを削除します。 任意のIRQLレベルで呼び出すことができます。

KeSetNotifEvent

タイプ通知イベント（手動リセット）の待機オブジェクトを通知します。 このオブジェクトの信号を待っていたすべてのスレッドは、実行準備完了状態になります。 それらの中に現在のスレッドよりも高い優先度を持つスレッドが存在する場合、現在のスレッドの実行は、最も高い優先度を持つスレッドに取って代わります。



オブジェクトは、KeResetEventが呼び出されるまで信号を送り続けます。



この関数は、IRQL = PASSIVE_LEVELでのみ呼び出すことができます。

KeSetNotifEventFromIsr

同じですが、IRQL> = DISPATCH_LEVELの呼び出しの場合。 この関数がISRから呼び出されると、フローの切り替えが発生した場合、ISRの完了後に切り替えられます。

KeSetSynchrEvent

タイプ同期イベント（自動リセット）の待機オブジェクトに信号を送ります。 このオブジェクトに保留中のフローがある場合、そのうちの1つは準備完了状態になり、オブジェクトはすぐに非信号状態に戻ります。 残りのスレッドは待機し続けます。 待機中のスレッドがなかった場合、オブジェクトは、一部のスレッドが待機関数またはKeResetEventを呼び出すまでシグナル状態のままになります。



複数のスレッドがそのようなオブジェクトのシグナリングを待機している場合、待機からの終了の順序は定義されていません。

待機して準備完了状態に切り替わったスレッドの優先順位が現在のものより高い場合、混雑が発生します。



この関数は、IRQL = PASSIVE_LEVELでのみ呼び出すことができます。

KeSetSynchrEventFromIsr

同じですが、IRQL> = DISPATCH_LEVELの呼び出しの場合。 この関数がISRから呼び出されると、フローの切り替えが発生した場合、ISRの完了後に切り替えられます。

KeWaitForObject

オブジェクトが信号を送るのを待っています（イベント）。 この関数が呼び出されたときにオブジェクトに信号が送られた場合、関数はすぐに戻ります。 同時に、同期イベントの場合、オブジェクトは未署名の状態にリセットされます。 オブジェクトにシグナルが送信されなかった場合、現在のスレッドはスタンバイモードになり、ディスパッチャは準備完了状態の他のスレッドからコードを実行します。



この関数は、IRQL = PASSIVE_LEVELでのみ呼び出すことができます。

ユーザーISR

これは、カスタム割り込みルーチンを実行する機能を意味します。 関数の形式では割り当てられませんが、ディスパッチャのソースには、呼び出しまたは挿入する場所があります。 ストリームと対話するために、このルーチンは関数KeSetNotifEventFromIsrおよびKeSetSynchrEventFromIsrを使用して、あるスレッドを「起動」し、別のスレッドを強制することができます。



ISRの実行では、どのスレッドにも属さない個別のスタック領域が使用されます。 ハードウェア割り込みを処理する場合、割り込みからの戻りアドレス（2バイト）のみがスレッドスタックにプッシュされます。 他のディスパッチャ関数もスタックを乱用しません。 したがって、スレッドの最小量のメモリを予約することにより、スレッドのスタックを節約できます。



マネージャー機能の残りは、ユーザープログラムから呼び出されることを意図していません。

特定のプロジェクトのディスパッチャを構成する

ソフトウェアプロジェクトでディスパッチャを使用するには、設定する必要があります。 ソースコードでは、各スレッドのスレッドデータ構造に記入する必要があります。 塗りつぶしの例はソースに記載されています。 記入する主なものは、ストリームスタックのアドレスです。 各スレッドのスタックの最後の2バイトには、そのエントリポイントのアドレスが含まれています。 定数NUM_THREADSを設定して、スレッドの数も指定する必要があります。 システム内のスレッドの最大数は255です。



システムの起動時には、すべてのスレッドが準備完了状態である必要があります。 最も低い優先度を持つ最後のスレッドは、スタンバイモードに移行しないでください。 このスレッドはSystem Idle Processに類似しており、問題を解決しませんが、未使用のプロセッサー時間を「燃やす」ことを目的としています。 HALTコマンドを周期的に実行することをお勧めします。



また、ディスパッチャ自体のメモリ内の配置、割り込みベクトルのテーブル、およびディスパッチャのISRアドレスを構成する必要があります。 ユーザーISRはISRマネージャーから呼び出されます。



待機オブジェクト用のメモリの割り当ては、原則として無制限の数にすることができますが、ユーザーの裁量に任されています。 これらのオブジェクトをスタックのグローバルスタティック変数に保存するか、ヒープマネージャーをプロジェクトに接続して、ヒープ上の指定されたオブジェクトにメモリを割り当てることができます。

問題状況

ディスパッチャによって実装される実行環境は、一般的なプリエンプティブマルチタスクシステムにとって問題となる状況によって特徴付けられます[1]。 これらには、飢Star、競合状態、および優先順位の逆転が含まれます。 最初の2つの問題は、適切なシステム設計、スレッド間のタスクの合理的な分散、優先順位の合理的な選択、および同期プリミティブ（主に自動リセット同期イベント）の使用によって解決できます。 3番目の状況は、スレッドとMutexタイプの同期オブジェクトに動的な優先順位がないため、ディスパッチャでは解決されません。 したがって、特定のプロジェクトでこの状況が発生した場合は、それを考慮し、必要に応じて上記の資金をディスパッチャーに追加する必要があります。

ソースコード

ディスパッチャーのソースコードは、データ構造、関数パラメーター、その他の情報の説明とともに、 GitHubからダウンロードできます 。

文学

1.ウィキペディア。 記事「 マルチタスク 」

2. ReactOS 。 ソースコード、ntoskrnlコンポーネント

3. Windows WDKドキュメント。 MSDN カーネルモードドライバーのアーキテクチャ