BOOK Preview インサイドMicrosoft Windows 第4版 上 第2章 システムアーキテクチャ 2.3 アーキテクチャ概要 書籍情報のページ 2005/08/02 |
|
2.3 アーキテクチャ概要
Windowsの設計目標の簡単な説明は終了しましたから、アーキテクチャを支える主要なシステムコンポーネントを紹介します。図2-1は、Windowsアーキテクチャの概要を示しています。図2-1はあくまでも概要を示しているだけです。ネットワーキングコンポーネントや各種のデバイスドライバ層などは、除外されています。
図2-1 Windowsアーキテクチャ概要 |
図2-1を見ると、Windowsオペレーティングシステムがユーザーモードとカーネルモードの2つの部分にわかれています。境界線の上にあるボックスはユーザーモードプロセスを、下にあるボックスはカーネルモードオペレーティングシステムサービスをそれぞれ表しています。第1章で触れたように、ユーザーモードスレッドは保護されたアドレスプロセスで動作し、システムスペースへのアクセスは禁止されます(ただし、ユーザーモードスレッドはカーネルモードで動作することもでき、その際には、システムスペースにアクセスできます)。表現を変えれば、境界線の上にあるシステムサポートプロセス、サービスプロセス、ユーザーアプリケーション、環境サブシステムは、それぞれ独自のプライベートプロセスアドレススペースを持っています。
境界線の上にある4つのユーザーモードプロセスは、次のような役割を持っています。
-
システムサポートプロセス ― Windowsサービスではなく、ログオンプロセスやセッション管理などの特定の機能を提供。システムサポートプロセスは、サービスコントロールマネージャ(SCM)によって起動されることはありません。詳細については第4章で説明。
-
サービスプロセス ― タスクマネージャやスプーラサービスを提供するWindowsサービス。サービスは基本的には、ユーザーログオンとは独立して動作する性格を持っています。Microsoft SQL ServerやMicrosoft Exchange Serverなどの多くのサーバーアプリケーションは、サービスとして動作するコンポーネントを持っています。
-
ユーザーアプリケーション ― ユーザーアプリケーションには、Windows 32ビット、Windows 64ビット、Windows 3.1 16ビット、MS-DOS 16ビット、POSIX 32ビット、およびOS/2 32ビットの6種類のタイプがあります。
-
環境サブシステムサーバープロセス ― オペレーティングシステムの「環境」(ユーザーやプログラマに応じた固有な環境)整備をサポートする機能。Windows NTは、もともとはWindows、POSIX、そしてOS/2という3 種類の環境を提供していました。OS/2はWindows 2000 からサポート外となり、Windows XP出荷時には、Windows サブシステムだけが基本製品内に含められるようになりました。改訂版POSIXサブシステムは、UNIX 製品版用の無料サービスの一部として提供されています。
図2-1を見ると、「サービスプロセス」と「ユーザーアプリケーション」ボックスの直下に「サブシステムDLL 群」というボックスがあります。Windows の世界では、ユーザーアプリケーションはネイティブWindows オペレーティングシステムサービスを直接呼び出すことはできません。その代わり、サブシステムダイナミックリンクライブラリ(DLL)を経由して、ネイティブサービスを呼び出しています。サブシステムDLLは、公開されている関数を、対応する内部Windows システムサービスコール(基本的には非公開)に変換する役割を引き受けているのです。この変換の過程では、ユーザーアプリケーションにサービスを提供する環境サブシステムが必要なメッセージを送信することもあります。
Windowsは、次のようなカーネルモードコンポーネントを持っています。
-
Windowsエグゼキュティブ ― メモリ管理、プロセスとスレッド管理、セキュリティ、I/O、ネットワーク、およびプロセス間通信などの基本的なオペレーティングシステムサービス。
-
Windowsカーネル ― スレッドスケジューリング、割り込み、例外通知、マルチプロセッサの同期などの低レベルオペレーティングシステム関数を提供します。また、Windows エグゼキュティブが内部で使用するルーチンセットと基本オブジェクトも提供しています。
-
デバイスドライバ ― ユーザーからのI/O呼び出し要求を特定のハードウェアデバイスI/O要求に変換するハードウェアデバイスドライバと、ファイルシステムやネットワークドライバなどのシステムサービスを提供するデバイスドライバ。
-
ハードウェア抽象化層(HAL) ― カーネル、デバイスドライバ、およびWindows エグゼキュティブをプラットフォーム固有のハードウェア機能から分離するコード層。たとえば、マザーボードの種類と違いなどはこのHAL で抽象化されます。
-
ウィンドウとグラフィック管理 ― グラフィカルユーザーインターフェイス(GUI)関数を実装するシステム。簡単に言ってしまえば、ウィンドウ、ユーザーインターフェイスコントロール、描画処理などを担当するWindowsのUSERとGDI関数を実装しています。
表2-1は、Windows のコアコンポーネントを実装するファイル名を紹介しています。本書では、ファイル名を使ってコンポーネントに言及することがありますから、表2-1のファイル名を知っていると便利なことがあります。このコンポーネントの詳しい説明は本章や後続の章で行います。
ファイル名 | コンポーネント |
Ntoskrnl.exe | エグゼキュティブとカーネル |
Ntkrnlpa.exe(32 ビットシ ステムのみ) | エグゼキュティブと物理アドレス拡張機能(PAE)を持つカーネル。PAEを活用すると、64GBまでの物理メモリが利用できるようになる。 |
Hal.dll | ハードウェア抽象化層 |
Win32k.sys | Windowsサブシステムのカーネルモード部 |
Ntdll.dll | エグゼキュティブ関数が使用する内部サポート関数とシステムサービスコールスタブ |
Kernel32.dll 、Advapi32. dll、User32.dll、Gdi32.dll | WindowsのコアサブシステムDLL |
表2-1 Windows コアコンポーネントと実装ファイル名 |
2.3.1 移植性
既に触れたように、Windowsは、IntelベースのCISC(Complex Instruction SetComputer)とRISC(Reduced Instruction Set Computer)をはじめとする、いろいろなハードウェアアーキテクチャをサポートするように設計されています。最初のWindows NT リリースは、x86とMIPSアーキテクチャをサポートしていました。時間を置かずして、Digital Equipment Corporation(後にCompaqに吸収され、その後Hewlett Packardと合併)のAlpha AXPもサポートされるようになりました(ただし、Alpha AXPは64ビットプロセッサであったため、Windows NTは32ビットモードで動作していました。Windows 2000開発段階では、ネイティブの64ビット版がAlpha AXP上で動作していましたが、市場に出されることはありませんでした)。4番目にサポートされたプロセッサアーキテクチャは、Windows NT 3.51がサポートしたMotorola PowerPCでした。しかし、このアーキテクチャサポートは、市場の変化もあり、Windows 2000が開発される頃には、MIPSと共に打ち切られました。また、CompaqはAlpha AXPアーキテクチャサポートから撤退してしまったため、Windows 2000は最終的に、x86 アーキテクチャだけをサポートする結果になりました。最新リリースであるWindows XPとWindows Server 2003は、Intel Itanium IA-64ファミリ、AMD x86-64ファミリ、Intel 64ビット拡張テクノロジ(EM64T)の3種類の64ビットプロセッサファミリを追加サポートしています(EM64TはAMD x86-64アーキテクチャと互換性を持っています)。後者の2つのプロセッサファミリは64ビット拡張システムと呼ばれていますが、本書では、x64と略記することにします。また、32ビットアプリケーションと64ビットWindowsの関係は、第3章で説明します。
Windowsは、次のような2つの方法でハードウェアアーキテクチャとプラットフォーム間の移植性を確保しています。
-
Windowsは複数の層で構成されるように設計されました。プロセッサアーキテクチャやプラットフォームに依存する低レベルシステムコードは個別のモジュールに実装され、上位層はアーキテクチャ間の違いの影響を受けることはありません。オペレーティングシステムの移植性を確保している主要な2つのコンポーネントは、(Ntoskrnl.exeに実装されている)カーネルと(Hal.dllに実装されている)ハードウェア抽象化層です。2つのコンポーネントの詳しい説明は後ほど行います。スレッドコンテキスト切り替えやトラップ処理などのアーキテクチャ固有機能は、カーネルに実装されています。マザーボードなどの、同一アーキテクチャのシステム間で異なる要素は、HALで吸収されます。メモリマネージャなどもアーキテクチャに依存する部分ですが、システム全体から見た場合、コード量としてはわずかです。
-
Windowsの大部分はCで、残りの部分の多くはC++で記述されています。アセンブリ言語も使用されているのは確かですが、システムハードウェアと直接通信する必要があるシステム機能(割り込みハンドラなど)や、パフォーマンスが要求される処理コード(コンテキスト切り替えなど)に限られています。アセンブリコードは、カーネルとHALだけではなく、オペレーティングシステムのコアコンポーネント(ロック命令やLPC 実装モジュール)、Windows サブシステムのカーネルモード部、あるいは後述するNtdll.dllのプロセス起動コードといったユーザーモードライブラリでも使用されています。
2.3.2 対称型マルチプロセッシング
マルチタスキングは、複数の実行スレッド間で1 つのプロセッサを共有するためのオペレーティングシステムの中核機能です。しかし、1台のコンピュータが複数のプロセッサを搭載しているときには、複数のスレッドが同時に実行可能となります。つまり、マルチタスキングオペレーティングシステムは複数のスレッドを同時に実行しているように見せかけますが、マルチプロセッシングオペレーティングシステムは見せかけではなく、それぞれのプロセッサ上で1つのスレッドを同時に動かしているのです。
本章の冒頭で触れたように、Windowsの設計目標の1つは、マルチプロセッサコンピュータシステムのサポートでした。Windowsは、対称型マルチプロセッシング(SMP)オペレーティングシステムです。マスタプロセッサというものは存在しません。つまり、ユーザースレッドとオペレーティングシステムは、任意のプロセッサ上で動作するようにスケジューリングされます。さらに、すべてのプロセッサは、1つのメモリスペースを共有します。このようなモデルは、非対称型マルチプロセッシング(ASMP)とは対照的といえます。ASMPモデルでは、オペレーティングシステムは1つのプロセッサ上でカーネルコードを実行し、ユーザーコードはそれ以外のプロセッサ上で実行されます。2つのマルチプロセッシングモデルの違いを図2-2に示します。
図2-2 SMPモデルとASMPモデル |
Windows XPとWindows Server 2003は、2つの新しいタイプのマルチプロセッサシステムをサポートしています。1つはハイパースレッディングアーキテクチャ、もう1つはNUMA アーキテクチャ(Non-Uniform Memory Architecture)と呼ばれています。これらのシステムについては、後ほど触れます。また、第6章では、2つのマルチプロセッサシステムのスレッドスケジューリングを取り上げています。
ハイパースレッディングは、1つの物理プロセッサから多数のプロセッサを論理的に作り出すために導入された技術です。作り出された個々の論理プロセッサは独自のCPU 状態を持ちますが、実行エンジンとオンボードキャッシュは共有します。簡単に言えば、ハイパースレッディングは、複数の論理CPUを効率的に使用するための技術といってよいでしょう。このため、ある論理CPUは、他の論理CPUがビジー状態にあるとき(たとえば、割り込み処理などを行い、他のスレッドの実行をブロックしているような場合)でさえも、自分の処理を継続できます。Windows XP から実装されたスケジューリングアルゴリズムは、ハイパースレッド対応マシンを最大限活用できるように改善されています。Windows XP環境では、アイドル状態にある物理プロセッサではなく、アイドル状態にある論理プロセッサをその都度選択し、そのプロセッサ上でスレッドをスケジューリングするようなこともできます。
NUMA アーキテクチャは、プロセッサをノードと呼ぶ小さな単位でグループ化します。各ノードは独自のプロセッサとメモリを所有し、キャッシュ構成のバス経由でより大きなシステムに接続されます。NUMA システム上のWindow は、すべてのプロセッサがすべてのメモリにアクセスできるため、基本的にはSMP システムです。しかし、ノードが持つローカルメモリへの参照は、他のノードが持つメモリへの参照より高速になる利点があります。NUMA システムは、使用されるメモリと同一ノードにあるプロセッサ上でスレッドをスケジューリングしてくれますから、そのシステムのパフォーマンスは向上することになります。また、メモリ割り当ても同一ノード内部で行いますから、パフォーマンスがさらに向上することになります(ただし、他のノード内のメモリを割り当てることができないわけではありません)。
Windows は最大32個までのプロセッサをサポートする設計になっていましたが、32という数値は上限ではありません。32という数値は、32ビットのデータ型として簡単に表現できることを指しているにすぎません。便宜上の数値であり、それ以上の意味はありません。同じように、64ビットWindows は最大64個のプロセッサをサポートするといわれていますが、64ビットマシンのワードが64ビットであることに起因する、便宜上の数値にすぎません。
サポートされる実際のプロセッサ数は、表2-3と表2-4のように、使用しているWindows バージョンに応じて決まります。プロセッサ数は、レジストリ内のHKLM\SYSTEM\CurrentControlSet\ControlSession
\Manager\LicensedProcessorsに格納されています。このレジストリ値を変更することは、ライセンス違反になりますから、注意が必要です。また、値を変更しただけでは、より多くのプロセッサが使えるようになるわけではありません。
Microsoftはパフォーマンスを考慮し、ユニプロセッサとマルチプロセッサ用のカーネルとHALを個別に提供しています(Windows 2000では、他の2、3のシステムファイルも個別に用意しています)。表2-2に示したように、Windows 2000のマルチプロセッサバージョンの場合、ユニプロセッサバージョンには見当たらない6個のシステムファイルがあります。32ビットのWindows XPとWindows Server2003では、異なるシステムファイルの数は3 個までに抑えられています。64ビットWindows システムの場合、PAE カーネルバージョンがないこともあり、ユニプロセッサとマルチプロセッサシステム間の違いはカーネルとHALだけになります。
Windowsをインストールすると、適切なファイルが選択され、\Windows\System32ディレクトリにコピーされます。どのファイルがコピーされているかを知りたい場合には、\Windows\Repair\Setup.logファイルを開いてみるとよいでしょう。コピーされているファイルの情報が書き込まれているはずです。
システムディスク上のファイル名 | 配布媒体上のユニプロセッサバージョン名 | 配布媒体上のマルチプロセッサバージョン名 |
Ntoskrnl.exe | Ntoskrnl.exe | Ntkrnlmp.exe |
Ntkrnlpa.exe(PAEカーネル:32ビットシステムのみ) | アーキテクチャフォルダ内のDriver.cabにあるNtkrnlpa.exe | アーキテクチャフォルダ内のDriver.cabにあるNtkrpamp.exe |
Hal.dll | システムタイプによる(表2-6のHALリスト参照) | システムタイプによる(表2-6 のHALリスト参照) |
Windows 2000のみ | ||
Win32k.sys | \I386\UNIPROC\Win32k.sys | \I386\Driver.cab にあるWin32k.sys |
Ntdll.dll | \I386\UNIPROC\Ntdll.dll | \I386\Ntdll.dll |
Kernel32.dll | \I386\UNIPROC\Kernel32.dll | \I386\Kernel32.dll |
表2-2 マルチプロセッサとユニプロセッサを構成するファイル |
注
|
|||||
|
|
キーとなるシステムファイルには、ユニプロセッサバージョンも用意されています。その最大の理由はパフォーマンスへの配慮です。実は、マルチプロセッサ間の同期は、その性質上、かなり複雑であり、時間的なコストも高くつくのです。こうした事情を考慮し、(Windowsを採用するシステムの多くを占める)ユニプロセッサシステム用のバージョンファイルを提供し、オーバーヘッドを軽減しているのです。
おもしろいことに、ユニプロセッサとマルチプロセッサ用のNtoskrnlは条件コンパイルされたものですが、Windows 2000のNtdll.dllとKernel32.dllはx86 LOCKとUNLOCK命令にパッチを当てて作成されています。つまり、LOCK とUNLOCK命令は、NOP(何もしない)命令と等価になり、マルチプロセッサの同期を取るために使用されています。
Windowsを構成する残りのシステムファイル(すべてのユーティリティ、ライブラリ、およびデバイスドライバ)は、ユニプロセッサとマルチプロセッサシステムの両方で同じものを使用しています。これらのファイルは、マルチプロセッサ間の同期を正確に取っています。このため、Windows アプリケーションやデバイスドライバなどのソフトウェアを開発するときには、Microsoftのアプローチを参考にするとよいでしょう。ポイントは、マルチプロセッサ間の同期なのです。ソフトウェアを設計/開発するときには、ユニプロセッサとマルチプロセッサの両システムでテストすることが大切です。
|
INDEX | ||
インサイドMicrosoft Windows 第4版 上 | ||
第2章 システムアーキテクチャ | ||
2.1 要求と設計目標/2.2 オペレーティングシステムモデル | ||
2.3 アーキテクチャ概要/2.3.1 移植性/2.3.2 対称型マルチプロセッシング | ||
2.3.3 スケーラビリティ/2.3.4 クライアントとサーバー間の違い/2.3.5 チェックビルド | ||
2.4 キーシステムコンポーネント/2.4.1 環境サブシステムとサブシステムDLL | ||
2.4.2 Ntdll.dll/2.4.3 エグゼキュティブ | ||
2.4.4 カーネル/2.4.5 ハードウェア抽象化層(HAL)/2.4.6 デバイスドライバ | ||
2.4.7 システムプロセス/まとめ | ||
「BOOK Preview」 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|