スレッドおよびスレッド処理

[アーティクル]
08/09/2011

オペレーティングシステムは、実行中の各アプリケーションをプロセスを使用して分離します。スレッドとは、オペレーティングシステムがプロセッサ時間を割り当てる対象の基本単位です。複数のスレッドが、そのプロセス内でコードを実行できます。各スレッドは、例外ハンドラー、スケジューリングの優先順位、およびスレッドコンテキストをスケジュールされるまでの間保存するために使用する一連の構造体を保持します。スレッドコンテキストは、スレッドがシームレスに実行を再開するために必要な、スレッドの CPU レジスタおよびスタックのセットを含むすべての情報を、該当するホストプロセスのアドレス空間に格納します。

.NET Framework は、オペレーティングシステムプロセスを、System.AppDomain で表されるアプリケーションドメインと呼ばれる軽量なマネージサブプロセスへとさらに分割します。 System.Threading.Thread で表される 1 つ以上のマネージスレッドが、同じマネージプロセス内にある任意の数のアプリケーションドメインで実行できます。各アプリケーションドメインは最初はシングルスレッドですが、そのアプリケーションドメイン内のコードで追加のアプリケーションドメインやスレッドを作成できます。そのため、マネージスレッドは、同じマネージプロセス内のアプリケーションドメイン間を自由に移動できます。1 つのスレッドだけを複数のアプリケーションドメイン間で移動させることもできます。

プリエンプティブなマルチタスクをサポートするオペレーティングシステムは、複数のプロセスからの複数のスレッドを同時に実行できます。システムは、使用できるプロセッサ時間をこれを必要とするスレッド間で分割し、各スレッドにプロセッサタイムスライスを順次割り当てることによってこれを実現します。現在実行中のスレッドはタイムスライスが経過すると中断され、別のスレッドが実行を再開します。システムは、スレッドを切り替えるときに、切り替える前のスレッドのスレッドコンテキストを保存し、スレッドキュー内にある次のスレッドの保存済みスレッドコンテキストを再読み込みします。

タイムスライスの長さは、オペレーティングシステムやプロセッサによって異なります。各タイムスライスは短いため、プロセッサが 1 つしか存在しない場合でも、複数のスレッドが同時に実行しているように見えます。マルチプロセッサシステムでは、実行可能スレッドが複数の有効なプロセッサに分散されているため、実際に複数のスレッドが同時に実行されます。

複数のスレッドを使用する場合

ユーザーとの対話を必要とするソフトウェアは、ユーザーのアクティビティにできるだけ迅速に反応して、充実したパフォーマンスを提供する必要があります。ただし、同時にこのソフトウェアは、ユーザーにデータを表示するために必要な計算をできるだけ高速に行う必要もあります。アプリケーションが 1 つの実行スレッドだけを使用する場合は、非同期プログラミングを .NET Framework リモート処理、または ASP.NET を使用して作成された XML Web サービスと組み合わせることで、使用しているコンピューターの処理時間だけでなく他のコンピューターの処理時間も利用できます。これにより、ユーザーへの応答を速くし、アプリケーションのデータ処理時間を短縮できます。また、多くの I/O 操作を行う場合は、I/O 完了ポートを使用すると、アプリケーションの応答を速くすることができます。

複数のスレッドを使用するメリット

ユーザーへの応答の高速化と、ジョブの実行に必要なデータの処理をほぼ同時に実現できる最も強力な方法は、複数のスレッドを使用することです。シングルプロセッサのコンピューターで複数のスレッドを使用すると、ユーザーイベント間の短い時間を利用してバックグラウンドでデータが処理されることによって、この効果が得られます。たとえば、別のスレッドが同じアプリケーション内でスプレッドシートのほかの部分を再計算している間に、そのスプレッドシートを編集できます。

同じアプリケーションをマルチプロセッサのコンピューターで実行すると、変更しなくてもパフォーマンスが大幅に向上します。単一のアプリケーションドメインで複数のスレッドを使用すると、次のタスクを実行できます。

ネットワーク経由での Web サーバーやデータベースとの通信。
時間のかかる処理の実行。
さまざまな優先順位のタスクの区別。たとえば、優先順位の高いスレッドは速度が重視されるタスクを管理し、優先順位の低いスレッドはほかのタスクを実行します。
ユーザーインターフェイスによる迅速な応答と、バックグラウンドタスクへの割り当て時間の両立。

複数のスレッドを使用するデメリット

オペレーティングシステムリソースの使用を最小にしてパフォーマンスを向上させるには、使用するスレッドをできるだけ少なくすることをお勧めします。また、アプリケーションをデザインするときは、スレッド処理にはリソース要件があること、競合が発生する可能性があることを考慮する必要があります。リソース要件は次のとおりです。

システムは、プロセス、AppDomain オブジェクト、およびスレッドが必要とするコンテキスト情報を格納するためにメモリを消費します。そのため、使用できるメモリの量によって、作成できるプロセス、AppDomain オブジェクト、およびスレッドの数は制限されます。
多数のスレッドを追跡するには、プロセッサ時間を大量に消費します。スレッドが多すぎると、ほとんどのスレッドで処理に重大な影響がでます。現在のスレッドのほとんどが 1 つのプロセスにある場合は、ほかのプロセスにあるスレッドのスケジュール頻度が低下します。
多数のスレッドを使用したコードの実行は制御が複雑なため、多くのバグの原因となる可能性があります。
スレッドを破棄するには、発生する可能性がある問題を認識して対処する必要があります。

リソースへの共有アクセスを提供すると、競合が発生する場合があります。競合を回避するには、共有リソースへのアクセスとの同期をとるか、またはアクセスを制御する必要があります。同じアプリケーションドメインまたは異なるアプリケーションドメインで、アクセスを正しく同期することに失敗すると、デッドロック (2 つのスレッドがお互いの完了を待って応答しなくなる状態) や競合状態 (2 つのイベントのタイミングによって予測できない動作が生じたために、異常な結果が発生した場合) などの問題が生じる可能性があります。システムには、複数のスレッド間でのリソース共有を調整するための同期オブジェクトが用意されています。スレッド数を減らすことで、より簡単にリソースの同期がとれるようになります。

同期を必要とするリソースは、次のとおりです。

システムリソース (通信ポートなど)
複数のプロセスによって共有されるリソース (ファイルハンドルなど)
複数のスレッドによってアクセスされる単一のアプリケーションドメインのリソース (グローバルフィールド、静的フィールド、インスタンスフィールドなど)

スレッド処理とアプリケーションのデザイン

一般に、他のスレッドをブロックしない比較的短いタスクを特定のスケジューリングを指定せずに実行する場合、複数のスレッドを処理する最も簡単な方法は、ThreadPool クラスを使用することです。ただし、次に示すように、独自のスレッドを作成した方がよい場合も多くあります。

タスクに特定の優先順位を設定する必要がある場合。
タスクが長時間実行して、ほかのタスクをブロックする可能性がある場合。
スレッドをシングルスレッドアパートメント内に配置する必要がある場合 (すべての ThreadPool スレッドがマルチスレッドアパートメント内にある場合)。
スレッドに関連付けられた、確立された ID が必要な場合。たとえば、そのスレッドをアボートまたは中断したり、名前で探索したりするには、専用のスレッドを使用する必要があります。
ユーザーインターフェイスと対話するバックグラウンドスレッドを実行する必要がある場合、.NET Framework Version 2.0 では、イベントを使用し、ユーザーインターフェイススレッドへのスレッド間マーシャリングによって通信する BackgroundWorker コンポーネントを利用できます。

スレッド処理と例外

スレッドで例外を処理します。スレッドで処理できない例外が発生すると、バックグラウンドスレッドの場合でも、通常、プロセスが終了します。この規則には、次の 3 つの例外があります。

Abort が呼び出されると、スレッドで ThreadAbortException がスローされる。
アプリケーションドメインがアンロードされるため、スレッドに AppDomainUnloadedException がスローされる。
共通言語ランタイムまたはホストプロセスがスレッドを終了する。

詳細については、「マネージスレッドの例外」を参照してください。

メモ
.NET Framework Version 1.0 および 1.1 では、共通言語ランタイムが、スレッドプールスレッドなどで一部の例外を通知なしにトラップします。このため、アプリケーション状態が破損し、最終的にアプリケーションが停止することにより、デバッグが困難になることがあります。