C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

TPL で メインスレッドの優先順位をあげる方法 [1]

[トピック内 33 記事 (21 - 33 表示)]  << 0 | 1 >>

■97813 / inTopicNo.21)  Re[10]: TPL で メインスレッドの優先順位をあげる方法
  
□投稿者/ WebSurfer (2297回)-(2021/07/17(Sat) 09:15:57)
No97811 (メタルスライム さん) に返信
> 解決方法を考えたので
> その概念について、皆様のご意見を聞かせてほしいです


> 【解決したい問題】
> ●マルチスレッド、tplなどのプログラムにキャンセルボタンを実装したい
> ●UIスレッドに負荷をかけるとキャンセルボタンが反応しない
>
> 【解決方法】
> 別のプロセスに頼るのが良いと考えました、具体的には下記の手順です

それで解決できると思うなら、人に聞く前に、まず自分でやってみたらどうですか?

回答者が「UIスレッドに負荷をかける」のをやめるようアドバイスしているのに、聞く
耳持たずで、相変わらずその致命的な点を改善しようとしない。

アドバイスを聞く耳持たないならここでは人に聞いても意味がないし、アドバイスを
くれた人に失礼。自助努力で解決してください。
 


引用返信 編集キー/
■97814 / inTopicNo.22)  Re[11]: TPL で メインスレッドの優先順位をあげる方法
□投稿者/ メタルスライム (23回)-(2021/07/17(Sat) 20:15:17)
WebSurfer様


アドバイスを聞いたからこその「次の展開」と考えてはいただけませんか?

私が部下なら
「致命的な欠陥」や「してはいけない理由」「失敗事例」
推奨しない理由。を教えてほしいのです


プログラム業界の禁忌ということであれば、それもひとつの理由です


客のクレームで絶対に今日解決しなければならない
と言われたことを想像してください

これは絶対してはいけないことですか?


引用返信 編集キー/
■97815 / inTopicNo.23)  Re[12]: TPL で メインスレッドの優先順位をあげる方法
□投稿者/ WebSurfer (2298回)-(2021/07/17(Sat) 20:46:36)
No97814 (メタルスライム さん) に返信

> アドバイスを聞いたからこその「次の展開」と考えてはいただけませんか?

いえ、何も聞いてないとしか思えない。もしくは理解できる能力がない。

> 私が部下なら
> 「致命的な欠陥」や「してはいけない理由」「失敗事例」
> 推奨しない理由。を教えてほしいのです

何を甘えたことを言ってるのかな? あなたは私の部下などではない赤の他人です。

部下なら戦力になってもらわないと困るし、部下を教育するのは上司の義務だと思っている
し、Face-to-face でやり取りして何が分からないかさえ分からない部下に何を教えればよい
か探って教えることができるので、やりようがありますけどね。

> プログラム業界の禁忌ということであれば、それもひとつの理由です

「UIスレッドに負荷をかける」なんてありえないと思ったらいいのでは? そうではないの
であれば、それをここの閲覧者の皆さんが納得できるように説明したら? それもやらないで
何でそんなことが言えるのかな?

> 客のクレームで絶対に今日解決しなければならない
> と言われたことを想像してください

ええ? あなたは仕事でやってるんですか? 今までのやり取りから推定できるあなたのレベル
からはとてもそうは思えないですけど・・・

もしホントに仕事でやってるなら、あなたの組織の上司・先輩・同僚に聞くのが筋ですよ。なんで
ここで聞いてるの?

> これは絶対してはいけないことですか?

そうです。あなたのレベルではとくに。

やっぱり話が通じない人だと確信しました。もう勝手にやってください。自分はあなたはもう相手に
したくない。撤退します。

引用返信 編集キー/
■97816 / inTopicNo.24)  Re[13]: TPL で メインスレッドの優先順位をあげる方法
□投稿者/ メタルスライム (24回)-(2021/07/17(Sat) 21:05:33)
WebSurfer様

部下の明確な提案に対して
具体的な理由を一つも言わずに全否定

一流の技術屋も集まる場所でそんな捨て台詞通りませよ。


引用返信 編集キー/
■97817 / inTopicNo.25)  Re[14]: TPL で メインスレッドの優先順位をあげる方法
□投稿者/ メタルスライム (25回)-(2021/07/17(Sat) 21:14:37)
サーバー管理者様

すみませんが、このスレッドを削除お願いします

そして、その前に私の立てたスレッドも私のレスも全て削除お願いしたいです
無理なお願いですが、ご検討お願いします
引用返信 編集キー/
■97818 / inTopicNo.26)  Re[15]: TPL で メインスレッドの優先順位をあげる方法
□投稿者/ サバ (3回)-(2021/07/18(Sun) 09:49:23)
WebSurferはコミュニケーションの講座を受講したが良い
コミュ障が回答してくるってすごく怖い
指原のお尻追っかけてるだけじゃダメ

引用返信 編集キー/
■97819 / inTopicNo.27)  Re[16]: TPL で メインスレッドの優先順位をあげる方法
□投稿者/ サバ (4回)-(2021/07/18(Sun) 10:31:28)
メタスラさんへ

UIスレッドはメッセージループを回していてそのループの中で画面の描画や入力の検知を行っているのでUIスレッドで時間のかかる処理やスリープを行うとループが回せなくなって画面の描画や入力の検知ができなくなるんよ

これはどうしようもない、時間のかかる処理をできるだけ別スレッドで行うようにするか、修正する時間がないなら応答なくなるけど処理してるから待っててねでユーザに納得してもらうかかな

昔々、GUIの描画をマルチスレッド化しようと色んな人が挑戦したけどことごとく失敗に終わって今のところGUIの描画をシングルスレッドで行うのがベストなアーキテクチャ

引用返信 編集キー/
■97820 / inTopicNo.28)  Re[17]: TPL で メインスレッドの優先順位をあげる方法
□投稿者/ メタルスライム (26回)-(2021/07/18(Sun) 19:16:18)
Azulean 様

すみませんご回答の内容をよく見ると、認識の違いがわかりました
既にUIの「表示」応答性の問題は解決済みです。
よって、フリーズを招く心配はありません。

ただただ、キャンセルボタンのキューを、優先的に挿入したいという状況ですので

UIの負荷を下げることは検討済みで
「スタック、キュー」の考え方で
UIスレッドに入るキューを一旦リストに格納して
自前で処理を実装すれば良いということまではわかっています

しかし、現在、問題なく動作しているそこそこ大きなプログラムですので
当然大きな改造をするのは危険ですので
プログラムの大改造をしたくないというのが現状です

現況を伝えられずすみません。

変なこと、というのも理解しております。
開発環境内でデバッグができないことをすることの意味がわかっているのか
ということかと思います



サバ様

先程メッセージループという概念を勉強しました、ありがとうございます
GUIの更新は永遠のテーマなのですね。
みなさん、マイクロソフトの推奨しない方法で、なんとか乗り切っているのが
現状なのでしょうか。



引用返信 編集キー/
■97821 / inTopicNo.29)  Re[18]: TPL で メインスレッドの優先順位をあげる方法
□投稿者/ Azulean (1199回)-(2021/07/18(Sun) 20:24:29)
2021/07/18(Sun) 21:31:05 編集(投稿者)

No97820 (メタルスライム さん) に返信
> ただただ、キャンセルボタンのキューを、優先的に挿入したいという状況ですので

Windows の仕様で固定ですので「できません」。

優先したいと思うほど、応答が悪いと言うことは、メインスレッドの処理負荷が高いか、メインスレッドにメッセージを投げすぎ(BeginInvoke しすぎ)というだけでしょう。

> しかし、現在、問題なく動作しているそこそこ大きなプログラムですので
> 当然大きな改造をするのは危険ですので
> プログラムの大改造をしたくないというのが現状です

判断は人それぞれなので止めることはできませんが、茨の道です。

Windows の仕様なので変えられませんので、あとは禁じ手である、UI スレッドをもう 1 つ作る方が先でしょうね。
キャンセルだけのプロセス作っても、そのプロセスからメインのプロセスで検知するまでが遅いだけだと思うので…。

※禁じ手というのは、推奨されないという意図からの発言です。スレッド作って、ShowDialog や Application.Run を呼べばそれらしく動くとは思いますが、無保証の領域=茨の道です。

> 先程メッセージループという概念を勉強しました、ありがとうございます
> GUIの更新は永遠のテーマなのですね。
> みなさん、マイクロソフトの推奨しない方法で、なんとか乗り切っているのが
> 現状なのでしょうか。

いやいや、Microsoft の推奨しない方法を選んだら、新しい Windows で動かなくなるなどの問題を引き越すリスクがあるので、Microsoft の推奨する方法の範囲で考えるのが先ですよ。
引用返信 編集キー/
■97822 / inTopicNo.30)  Re[19]: TPL で メインスレッドの優先順位をあげる方法
□投稿者/ メタルスライム (27回)-(2021/07/19(Mon) 01:05:47)
Azulean様

なぜゆえに下記のレスのみ完全スルーするのですか?
UIの負荷を下げる方法は検討済みでそれが最善なのは既知の上での質問です

>UIの負荷を下げることは検討済みで
>「スタック、キュー」の考え方で
>UIスレッドに入るキューを一旦リストに格納して
>自前で処理を実装すれば良いということまではわかっています


具体的なコードの記載はしておりませんが
Azulean様は皆が認める一流の技術者ですので
私としては、せめて、この考え方に対しての具体的な感想をいただきたいです。



サバ様
サバという名前ですが、サバ管様ではないですよね?
もし、そうであれば、スパッとスレッドを削除してください

ところで、サバ様は WebSurfer様のHPを御覧いただいたことはございますか?
今回、私がTPLを勉強するのに最も勉強になったのが
WebSurfer様の具体的な結果の実例です。
サバ様がWebSurfer様に辛辣な発言をされていますが、
是非一度御覧ください
素晴らしい情報発信をされているのは間違い有りません。

私は「自称」アスペルガーですので、
すみませんが配慮にかけるところはありますが正直なレスしかしません
WebSurfer様のHPは素晴らしいです。



引用返信 編集キー/
■97823 / inTopicNo.31)  Re[20]: TPL で メインスレッドの優先順位をあげる方法
□投稿者/ Azulean (1200回)-(2021/07/19(Mon) 06:40:01)
2021/07/19(Mon) 07:10:32 編集(投稿者)

No97822 (メタルスライム さん) に返信
> なぜゆえに下記のレスのみ完全スルーするのですか?

「プログラムの大改造をしたくないというのが現状です」という印象に引っ張られたからだと思います。

・もし意見を求めていたのであれば、「意見ください」とかスルーしづらいようにしていただけると助かります。
・この考えだからいけるはずだ…という意思表明だったのであれば、キューは万能ではないので、使い方次第ということもあって賛同・否定もなく、中立なのでコメントしづらいところです。


> >UIの負荷を下げることは検討済みで
> >「スタック、キュー」の考え方で
> >UIスレッドに入るキューを一旦リストに格納して
> >自前で処理を実装すれば良いということまではわかっています

どのスレッドで何をするように考えているか、日本語の箇条書きや、擬似コードでも良いからサンプル示してもらわないと、たぶん、認識が合わないと思います。


[1] BeginInvoke する頻度を落とすためのキュー
これは効果があるかもしれない。
BeginInvoke の秒あたりの呼び出し回数を大幅に下げられるなら効果がありそう。
(問題が過剰メッセージの場合。UI スレッド側処理の負荷が問題なら軽減レベルで、解決しない可能性あり)


(イメージ:バックグラウンド側での対策)
BeginInvoke したい場面になった

BeginInvoke 実行待ちがあるか?

BeginInvoke 実行待ちがあればキューに積むだけ、なければキューに積んで BeginInvoke

次の処理へ

(印象)
BeginInvoke の回数を減らせているので、効果はありそう。
ただし、キュー管理の部分でスレッド間排他(Lock)が必要なので、バックグラウンド側の実行パフォーマンスが落ちる恐れあり。
また、キューに積んだとしても、メッセージの頻度が減るだけで、メインスレッド側での処理量が減らないなら、効果が限定的になる恐れあり。

もし、マルチスレッドでの Lock の経験が薄い場合は、マルチスレッドでのデザインパターンの本も読んでおくとよいかもしれません。(十分に経験がある場合はすみません…)
一例: https://www.amazon.co.jp/dp/B00I8AT1BS/


[2] UI スレッドに入ってきた処理をキュー管理する
対策する前から存在している、「Windows が提供するメッセージループの仕組み」自体が「キュー」ですが、ここを変更することはできません。
メッセージループのメッセージキューに入ってくる順序が変わらない以上、BeginInvoke で呼ばれたあとの処理でキューを作っても、効果は期待できない認識です。

(イメージ:UI スレッド側??)
BeginInvoke で呼び出された関数に入る

ここでキューを何かする??? (イメージつかず)


このケースだった場合、今やりたいことは、「Windows が提供するメッセージループのメッセージキューでの優先度変更」のはずですので、この [2] の考え方では対処すべきところよりもあとになってしまっています。


> 具体的なコードの記載はしておりませんが
> Azulean様は皆が認める一流の技術者ですので
> 私としては、せめて、この考え方に対しての具体的な感想をいただきたいです。

そういった持ち上げ方はやめていただけると助かります。
Web 上での活動は私の一面でしかないので、私個人を知らない人から言われるのは違和感が強いことと、
私以外の誰に対する発言であっても「こういった人のはずだから答えてもらえるはず」だと、当人にプレッシャーを与える、悪い言い方をすれば、行動の強要のような印象を与えることにつながるため。

Web の掲示板・フォーラムはあくまで、善意・厚意で成り立っていますので、誰かの負担を求める恐れのある発言は避けましょう。
引用返信 編集キー/
■97824 / inTopicNo.32)  Re[10]: TPL で メインスレッドの優先順位をあげる方法
□投稿者/ kiku (241回)-(2021/07/19(Mon) 10:39:36)
2021/07/19(Mon) 10:41:56 編集(投稿者)

すみません。
ちゃんと最後まで読まずに投稿したので、一旦削除します。
引用返信 編集キー/
■97825 / inTopicNo.33)  Re[11]: TPL で メインスレッドの優先順位をあげる方法
□投稿者/ PATIO (6回)-(2021/07/19(Mon) 13:46:16)
2021/07/19(Mon) 13:50:33 編集(投稿者)
2021/07/19(Mon) 13:50:28 編集(投稿者)

静観してましたが、Windowsの基本的な仕組みとか
最近ではあまり聞かなくなったWindowメッセージのハンドラは出来る限り短い時間で
処理を完了してOSに処理を返さないといけないという考え方とか
そういう話が欠落している気がします。
最近、あまりうるさく言う人がいなくなった所為か、
実行中にウインドウのタイトルに「応答なし」が表示されるようなプログラムが
Web上でも当たり前のように公開されていたりします。

元々、Windowsのようにイベントドリブンで動作するシステムは
イベントハンドラ内に長時間滞留するようなプログラムを組んではいけないと言う事になっています。
なので、マルチスレッドを使用するとか、処理を細かく分解して自前でマルチスレッドもどきを
実装する等の努力を行って処理を組んでいました。

マルチスレッドに関しては、使うのであればちゃんと理解した上で使用する必要があります。
便利なライブラリが提供されていても大元の動きを理解していないと使いこなせません。

あと、パラレル処理のライブラリとUIスレッドと重い処理をマルチスレッド化する事は
直接の関係はありません。「応答なし」を出さない為にパラレル処理のライブラリは使えません。
重い処理を高速化するパラレル処理と「応答なし」を出さない為のマルチスレッド化は分けて考えるべきです。
「応答なし」が出ないようにして、かつ処理を中断する仕組みを組み込む事が出来るようになったう上で
その中で重い処理を高速化するパラレル処理をどう組み込むのかを考えましょう。

あと、聞いている限りでは大改造をせずに言われている状態にするのは無理だと思います。
仮に対処療法的な方法で対応したとしてもあるケースではうまく行くが別のケースではうまく行かないというような状態になりそうです。
引用返信 編集キー/

このトピックをツリーで一括表示

<前の20件
トピック内ページ移動 / << 0 | 1 >>

このトピックに書きこむ