-1

2 つのポイントが GUI スレッドの同じ部分にアクセスすることはありませんが、GUI にいくつかの変更を加えるアプリケーションを作成しています。このアプリケーションは現状では完全にスレッド セーフであり、その理由は簡単に理解できます (GUI を変更する呼び出し元が 1 つあり、残りの呼び出し元は外部クラス オブジェクトを変更します。これらのオブジェクトは、ロックを回避して GUI コントロール スレッドによって取得されます。 )

私が疑問に思っているのはこれです、どこまで行けばいいですか?つまり、スレッドを追加するたびに、GUI が応答しなくなったことが原因でしたが、私はソフトウェア テスターなので、GUI が更新されるのを 0.5 秒待つことができなかったことが原因である可能性があります。

では、小規模なアプリケーションの妥当な量はいくつのスレッドでしょうか? 私は自分自身を特定の量に制限する必要がありますか?それとも、気が狂って GUI をスムーズにする必要がありますか? ここでの本当の質問、つまり答えのある質問は、次のようなものだと思います。

可能な限り複数のスレッドを使用することは生産的ですか、それともあまりにも多くのスレッドを使用することは有害ですか、それとも効率的で効果的なアプリケーションを作成するために慎重にバランスをとる必要があるものですか?

ありがとう

4

2 に答える 2

0

MVC モデルを確認する必要があります。C# のウィンドウの通常のフレームワークではこれがあまり強制されないことはわかっていますが、ショーケースからデータを分離できれば、変更がはるかに簡単になります。

スレッド番号についても...私はそれらをできるだけ避ける傾向がありますが、常に可能であるとは限りません. これにより、あらゆる種類の同期の問題、競合状態、およびデッドロックが発生し、適切に把握してデバッグするのが非常に困難になります。

于 2013-06-07T22:25:38.463 に答える