与えられたタスクを達成するためにどちらかを使用することの長所と短所は何ですか。
百万ドルの質問は、どれをいつ使用するかです。
どうもありがとう。
与えられたタスクを達成するためにどちらかを使用することの長所と短所は何ですか。
百万ドルの質問は、どれをいつ使用するかです。
どうもありがとう。
「スレッド」とは、System.Threading.Threadクラスを明示的に使用して独自のスレッドを作成、構成、および開始することを意味する場合、答えは、これを行うと、スレッドをプルするだけでなく、より多くのcpuサイクルが必要になるということです。スレッドプールから(wjhichは他の手法が行うことです)、スレッドの優先順位や、スレッドプールスレッドを使用しても得られない他のいくつかの特性を指定できるため、柔軟性が向上します。
「スレッドプール」アプローチは、必要なスレッドの数が設計時にわからない場合に適しています。プールには最初、少数のスレッドが含まれており、それらを呼び出す準備ができています。オンデマンドで新しいスレッドを動的に作成でき、未使用のスレッドの作成、調整、および削除を管理します。プールからスレッドにアクセスして使用するために使用できるメカニズムは3つあります。
この素晴らしいスレッドの概要を見てください:
[BackgroundWorker]は次の機能を提供します。
中止を使用せずに終了するようにワーカーに通知するための「キャンセル」フラグ
進捗状況、完了、キャンセルを報告するための標準プロトコル
IComponentの実装により、ワーカースレッドのVisualStudioDesigner例外処理に配置できます。
ワーカーの進行状況または完了に応じてWindowsフォームとWPFコントロールを更新する機能。
最後の2つの機能は特に便利です。つまり、workerメソッドにtry / catchブロックを含める必要がなく、Control.Invokeを呼び出さなくてもWindowsフォームとWPFコントロールを更新できます。
UI(WinFormsまたはWPF)を操作する必要がない場合にのみスレッドを作成し、UIを処理する必要がある場合はバックグラウンドワーカーを使用します。
UIとバックグラウンドワーカーに関する多くの問題を回避できます。
私は、Threadsが行うことのラッパーとしてBackgroundWorkerを関連付けるために使用します。そのため、GUI作業ではBackgroundWorkerを使用し、より専門的またはダーティなジョブ(Windowsサービスなど)ではスレッドを使用します。
BackgroundWorkerクラスは、フォームにスレッドを追加して、UIをブロックせずに重い操作を実行する簡単な方法です。スレッドでも同じことができますが、コーディングが少し多くなります。
BackgroundWorkerクラスは、UIスレッドのコンテキストに切り替えられるイベントを提供するだけですが、混同しないでください。DoWorkイベント(実際に作業を行う場所)は引き続き別のスレッドのコンテキストで実行され(これが全体のポイントです)、そこであらゆる種類のUIインタラクションまたは更新を実行すると、例外がスローされます。最高で、最悪の場合はクラッシュします。バックグラウンドワーカーは、UIの更新が必要で、スコープがフォームのスコープを超えないようなことをしようとしているときに、フォームで使用する必要があります。その他のバックグラウンド操作については、ThreadPool(短期間の操作の場合)を使用するか、独自のスレッドを作成することを検討してください。
BackgroundWorkerは、ProgressChangedイベントで便利な機能を提供しますが、あまり快適にならずに、DoWorkでUIの更新を開始してください。