c# - マルチスレッド

Question

現在作業中のアプリケーションは、ユーザーが[送信]ボタンを押したときに発生するI / OまたはCPUを集中的に使用するアクション（ファイル圧縮、ファイル転送、サードパーティAPIとの通信など）を実行します。

私は現在、これらのアクションをメインアプリケーション内の別々のスレッドにプッシュする必要があることを雇用主に説得しようとしています（常に最大2つのワーカースレッドがアクティブである必要があります）が、私の同僚は次のように主張しています：

優先度の低いスレッドで実行される余分な処理は、GUIの使いやすさに影響を与える可能性があります。

私の見解では、I / OまたはCPUを集中的に使用するアクティビティをワーカースレッドにプッシュし、進行状況のレポート中にInvoke呼び出しを使用してUIを更新することは、集中的なアクティビティを処理するためのかなり標準的な方法です。

私は間違っていますか？もしそうなら、誰かが説明を提供できますか？

編集：

これまでの回答ありがとうございます。

明確にする必要があります。非ブロッキングに対する同僚の解決策は、フォルダーをスキャンしてファイルの圧縮/転送アクティビティを処理するタイマーループを含む子プロセスを生成することです。（これはサードパーティのAPIへの呼び出しをカバーしていないことに注意してください-私は彼の解決策が何であるかわかりません。

このアプローチの主な問題は、メインアプリケーションがアクティビティの状態に関するすべてのスコープを失うことです。これにより、IMHOがさらに複雑になります（進行状況レポートの解決策は、両方のプロセスでWindowsメッセージポンプを公開し、 2つのプロセス）。

Answer 1

あなたは正しいです。バックグラウンドスレッドは、呼び出し操作を介して、説明したとおりにUIをアクティブに保つための本質です。すべてをGUIスレッドに保持すると、最終的にはプラブが詰まり、GUIが応答しなくなります。

Answer 2

決定的な答えは、それを概念実証として実装し、アプリのプロファイルを作成して、パフォーマンスへの潜在的な影響の種類が存在するかどうかを確認することです。多分

そうは言っても、それは私にはゴミのように聞こえます。実際、これはまったく逆です。UIの応答性を維持するには、多くの場合、追加のスレッドを使用するのが最善の方法です。

特にタスク並列ライブラリのようなものでは、基本的なマルチスレッド化はそれほど難しくありません。

Answer 3

はい。それで合っています。一般的な原則として、ユーザーへの応答とユーザーインターフェイスの最新の維持を担当するスレッド（通常はUIスレッドと呼ばれます）を使用して、長時間の操作を実行しないでください。
経験則として、約30ミリ秒より長くかかる可能性のあるものはすべて、UIスレッドから削除する候補です。これは少し攻撃的です— 30msは、ほとんどの人が瞬間的ではないと感じる最短の間隔であり、実際には、映画の画面に表示される連続するフレーム間の間隔よりもわずかに短いです。