|
ユーザーインターフェイススレッド (User interface thread) とは、グラフィカルユーザインタフェースでのメインスレッドのことを指す。UIスレッドと表記されることもある。本項では、GUIでのマルチスレッドに関するデザインパターンを記載する。ユーザーインターフェイススレッドは、Javaではイベントディスパッチスレッド、Adobe Flashではprimordial workerと呼ばれる。 ==歴史的経緯== GUIアプリケーションにおいて、応答性を維持するためには、基本的にフレームの描画およびユーザー応答（さまざまなユーザー入力に対するアクション）はできるかぎり高いフレームレートで処理しないといけない〔必要となるフレームレートは、アプリケーションの用途やモニターのリフレッシュレートなどの環境によっても異なる。VRでは120fpsなど、さらに高いフレームレートが要求される。〕。例えば60fps (frames per second) の場合、1フレームの処理を1/60秒=約16ミリ秒以内に完了する必要がある。しかし、たとえどれほどプロセッサーの性能が向上したとしても、I/O処理や画像・動画のデコード、通信接続の確立など、完了までに長時間かかってしまう処理は必ず存在する。そういったものを含めて、すべての処理を1つのスレッドだけで実行すると、長時間かかる処理を実行している間はフレーム描画やユーザー応答の処理ができないため、UIの反応がなくなってしまう（ハングアップ、フリーズ）〔Windows アプリケーションのハング状態の防止 〕。長時間かかる処理の途中に、フレーム描画やユーザー応答に関わるメッセージ処理をときどき挟みながら、長時間かかる処理を少しずつ進める、という方法もあるが、スマートでないうえに適用限界がある。応答性の低下を防ぐためにマルチスレッド化が必要だが、それをどのようにしてソフトウェアの構造設計に持ち込むか、ということに関して、歴史的には1980年代から色々と議論があった。 例えば、Java の AWT では、1996年の最初の時点では、単純にスレッド間でデータ共有型のマルチスレッドになっていた。しかし、データ共有するには、ロックをかけないといけないが、親コンポーネントから子コンポーネントを呼んだり、コールバックで子から親を呼んだり、アプリケーションからGUIライブラリを呼んだり、GUIライブラリからアプリケーションをコールバックしたりと、双方向に呼び出すことが多く、異なるスレッド間で双方向に呼び合うときは、ロックの順番に注意を払う必要がある。これはソフトウェアが非常に複雑になる原因となってしまう。また、ロック順序のミスが引き起こすデッドロックは常にではなくたまに発生したりすることの多いバグ（時間的確率要因が関与する偶発性のあるバグ）であり、バグ取りが大変になるという問題があった〔Multithreaded toolkits: A failed dream? 〕。 そこで、1997年の Java の Swing からは、UI の操作は全てメインのUIスレッドであるイベントディスパッチスレッドから操作しなくてはならない、というルールを設けた。そして、2006年の Java 6 から、UI で重い処理をするために、ワーカーデザインパターンを採用した javax.swing.SwingWorker を搭載した。では、多くのUIライブラリが、UIスレッドに操作を限定することと、ワーカーデザインパターンの組み合わせを採用している。 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「ユーザーインターフェイススレッド」の詳細全文を読む スポンサード リンク
|