GUIプログラミングでスレッドの安全性を確保するのはなぜ呼び出し側の責任ですか？

多くの場所で、UIコンポーネントを更新するときにUIスレッド上にいること（具体的には、Javaスイングでは、イベントディスパッチスレッド上にいることを確認することは呼び出し側の責任であることは、標準的な知恵¹です） 。

これはなぜですか？イベントディスパッチスレッドは、MVC / MVP / MVVMのビューの問題です。ビュー以外の場所で処理するには、ビューの実装と、そのビューの実装のスレッドモデルとの間に密結合を作成します。

具体的には、Swingを使用するMVC設計のアプリケーションがあるとします。呼び出し元がイベントディスパッチスレッドのコンポーネントの更新を担当している場合、JavaFX実装のSwing View実装を交換しようとすると、代わりにJavaFXアプリケーションスレッドを使用するようにすべてのプレゼンター/コントローラーコードを変更する必要があります。

だから、私は2つの質問があると思う：

1. UIコンポーネントのスレッドの安全性を確保するのは、呼び出し側の責任なのはなぜですか？上記の推論の欠陥はどこにありますか？
2. これらのスレッド安全性の懸念を疎結合しながら、適切にスレッドセーフであるようにアプリケーションを設計するにはどうすればよいですか？

MCVE Javaコードを追加して、「呼び出し側の責任」が意味することを説明します（ここには、私がやっていませんが、できる限り最小限にするために他の良い習慣があります）。

責任者である発信者：

public class Presenter {
  private final View;

  void updateViewWithNewData(final Data data) {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        view.setData(data);
      }
    });
  }
}

public class View {
  void setData(Data data) {
    component.setText(data.getMessage());
  }
}

責任のあるビュー：

public class Presenter {
  private final View;

  void updateViewWithNewData(final Data data) {
    view.setData(data);
  }
}

public class View {
  void setData(Data data) {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        component.setText(data.getMessage());
      }
    });
  }
}

_{1：その投稿の作成者は、スタックオーバーフローのSwingで最高のタグスコアを獲得しています。彼はこれをあちこちで言っており、私もそれが他の場所での発信者の責任であることを見てきました。}

失敗した夢のエッセイの終わりに向かって、Graham Hamilton（主要なJavaアーキテクト）は、開発者が「イベントキューモデルと同等性を維持するためには、さまざまな非自明なルールに従う必要があり、明示的かつ明示的にイベントキューモデルは、「人々がより確実にモデルに従うことができ、したがって、確実に動作するGUIプログラムを構築するのに役立つようです。」

言い換えると、イベントキューモデルの上にマルチスレッドファサードを配置しようとすると、デバッグが非常に困難な非自明な方法で抽象化が漏れることがあります。それは紙の上で動作するように思えますが、生産ではバラバラになってしまいます。

単一のコンポーネントの周りに小さなラッパーを追加しても、ワーカースレッドからプログレスバーを更新する場合のように、おそらく問題にはなりません。複数のロックを必要とするより複雑なことを行おうとすると、マルチスレッドレイヤーとイベントキューレイヤーがどのように相互作用するかを推論するのが非常に難しくなります。

これらの種類の問題は、すべてのGUIツールキットに共通していることに注意してください。プレゼンター/コントローラーのイベントディスパッチモデルは、特定のGUIツールキットの同時実行モデルにのみ密接に結合しているのではなく、すべてのモデルに結合しています。イベントキューインターフェイスは、抽象化するのが難しいものであってはなりません。

GUI libをスレッドセーフにすることは、大きな頭痛とボトルネックであるためです。

GUIの制御フローは、多くの場合、イベントキューからルートウィンドウ、GUIウィジェット、アプリケーションコードからルートウィンドウまで伝播されるウィジェットの2方向に進みます。

ルートウィンドウをロックしない（多くの競合を引き起こす）ロック戦略を考案することは困難です。別のスレッドがトップダウンでロックしているときにボトムアップでロックすると、すぐにデッドロックを達成できます。

また、現在のスレッドが毎回guiスレッドであるかどうかを毎回確認するのはコストがかかり、特に読み取り更新書き込みシーケンスを実行している場合、実際にguiで何が起こっているかについて混乱を招く可能性があります。競合を避けるために、データをロックする必要があります。

（共有メモリモデルの）スレッド化は、抽象化の努力に逆らう傾向があるプロパティです。単純な例はSet-typeです。and Contains(..)およびAdd(...)and Update(...)は、シングルスレッドシナリオでは完全に有効なAPIですが、マルチスレッドシナリオではが必要AddOrUpdateです。

UIにも同じことが当てはまります。リストの一番上にあるアイテムの数を含むアイテムのリストを表示する場合は、変更するたびに両方を更新する必要があります。

1. ロックでは操作の順序が正しいことを確認できないため、ツールキットではこの問題を解決できません。
2. ビューは問題を解決できますが、リストの一番上の数字がリスト内のアイテムの数と一致する必要があるというビジネスルールを許可し、ビューを介してのみリストを更新する場合のみです。MVCが何であるかは正確ではありません。
3. プレゼンターはそれを解決できますが、ビューにはスレッド化に関して特別なニーズがあることを認識する必要があります。
4. マルチスレッド対応モデルへのデータバインディングも別のオプションです。しかし、それはモデルをUIの懸念事項で複雑にします。

それらのどれも本当に魅力的ではありません。プレゼンターにスレッド処理の責任を負わせることは、それが優れているからではなく、うまく機能し、代替案がより悪いために推奨されます。

私はこの問題を議論する非常に良いブログを読んでいます（カール・ビーレフェルトが言及）、基本的に言っているのは、UIキットをスレッドセーフにすることは非常に危険であり、デッドロックを引き起こし、その方法によって異なりますフレームワークへの競合状態の実装。

パフォーマンスに関する考慮事項もあります。それほど多くはありませんが、Swingが最初にリリースされたとき、そのパフォーマンスはひどく批判されていました（悪い）が、それは実際にはSwingのせいではありませんでした。

SWTは、違反ではない場合に例外をスローすることにより、スレッドセーフの概念を実施します。

たとえば、ペイントプロセスを検討する場合、要素がペイントされる順序は非常に重要です。1つのコンポーネントのペイントが画面の他の部分に副作用を与えないようにする必要があります。ラベルのテキストプロパティを更新できても、2つの異なるスレッドでペイントされた場合、出力が破損する可能性があると想像してください。したがって、すべてのペイントは通常、要件/要求の順序に基づいて単一のスレッド内で行われます（ただし、実際の物理的なペイントサイクルの数を減らすために凝縮される場合があります）

SwingからJavaFXへの変更について言及しましたが、ほぼすべてのUIフレームワーク（シッククライアントだけでなくWebも）でこの問題が発生しますが、Swingは問題を強調するもののようです。

UIの呼び出しが正しく同期されるようにすることを目的とする中間層（コントローラーのコントローラー？）を設計できます。UI APIの観点からAPIの非UI部分を設計する方法を正確に知ることは不可能であり、ほとんどの開発者は、UI APIに実装されたスレッド保護が制限的であるか、ニーズを満たしていないと文句を言います。ニーズに基づいて、この問題をどのように解決したいかを決定できる方が良い

考慮する必要がある最大の問題の1つは、既知の入力に基づいて、イベントの特定の順序を正当化する機能です。たとえば、ユーザーがウィンドウのサイズを変更した場合、イベントキューモデルは特定のイベントの順序が発生することを保証しますが、これは単純に思えるかもしれませんが、キューが他のスレッドによるイベントのトリガーを許可した場合、その順序を保証できなくなりますイベントが発生する可能性があり（競合状態）、突然、異なる状態について心配し始め、何か他のことが起こるまで何もしないで、状態フラグを共有しなければならなくなり、スパゲッティになります。

OK その上、スレッドAの後でスレッドBがイベントを生成するという保証はまだありません。

人々が自分のコードについて考えなければならないことに動揺する主な理由は、彼らが自分のコード/デザインについて考えさせられるからです。「なぜもっと簡単にできないのですか？」単純な問題ではないため、これ以上単純にすることはできません。

PS3がリリースされ、SonyがCellプロセッサをアップトークしたときのことを覚えています。ロジックの個別のラインを実行し、オーディオ、ビデオをデコードし、モデルデータをロードして解決することができます。あるゲーム開発者は、「それはすべて素晴らしいですが、どのようにストリームを同期しますか？」と尋ねました。

開発者が話していた問題は、ある時点で、それらの個別のストリームをすべて出力用の単一パイプに同期する必要があることでした。貧しいプレゼンターは、彼らがよく知っている問題ではなかったので、ただ肩をすくめた。明らかに、彼らは今この問題を解決する解決策を持っていますが、それは当時面白いものです。

現代のコンピューターは多くの異なる場所から同時に多くの入力を取得していますが、そのすべての入力を処理して離れた場所にいるユーザーに配信する必要があるため、他の情報の表示を妨げる​​ことはないため、複雑な問題です。単一のシンプルなソリューション。

今、フレームワークを切り替える機能を持っているので、それを設計するのは簡単ではありませんが、MVCを少し取ってください、MVCは多層にすることができます、つまり、UIフレームワークの管理を直接扱うMVCを持つことができます次に、他の（潜在的にマルチスレッド化された）フレームワークとの相互作用を処理する上位層MVCで、下位MVC層に通知/更新する方法を決定するのはこの層の責任です。

その後、コーディングを使用して設計パターンとファクトリーまたはビルダーのパターンをインターフェースし、これらの異なるレイヤーを構築します。つまり、マルチスレッドフレームワークは、アイデアとして中間層を使用することでUI層から切り離されます。