- 1 名前：デフォルトの名無しさん mailto:sage [2017/01/28(土) 16:46:53.58 ID:op86qfG/.net]
- ■Visual Studio 2015 Community & Express (無償の統合開発環境)等はこちら
www.visualstudio.com/downloads/
■コードを貼る場合はこちら
ideone.com/
■前スレ
C#, C♯, C＃相談室 Part91
echo.2ch.net/test/read.cgi/tech/1467211515/
■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
- 610 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 08:05:24.99 ID:eX8m9MWo.net]
- WinFormsやWPFを含めたGUIフレームワークって
イベントハンドラなどのユーザーコードに制御を渡す前後で
一時的に状態を変えたりしてることが多いから、
それ以外のタイミングで触られると壊れる
結局それを防ごうとするとユーザーコードの実行タイミングまでブロックすることになるので、
Invokeと変わらなくなる
- 611 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 08:14:01.02 ID:HovpjxiM.net]
- >>584
> マルチスレッドにしようと思ったらできるんだから
話がループしてるぞ
やればできるけどコールバックとかでロックの管理が面倒だしUIだから極限まで性能追い求める必要もないから
>> UI の操作は全てメインのUIスレッドであるイベントディスパッチスレッドから
>> 操作しなくてはならない、というルールを設けた。
ってことだろ
- 612 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 10:27:00.68 ID:BTeOg9CT.net]
- >>564
COMのアパートメント問題を解決するためじゃないの？
厳密にはInvokeしなくて良いケースもあるけど、それを保証する方法が皆無に等しいという。
ウインドウメッセージ云々とか、本質とはかけ離れている気が。
- 613 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 12:30:56.91 ID:Un9Q+jtZ.net]
- >>582
もう誰も使っている奴いないだろう、放棄されて保守だけが残っている。
こういう技術はいずれそうなるよ
- 614 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 12:53:23.45 ID:Un9Q+jtZ.net]
- >>586
UI側がバージョン管理システムみたいな扱いをすればいいんだと思うけどね
非ロック型で同期をとる方法としては有効だと思う。
いわゆる
読み込んで、内容を変更して、読み込み時点データとともにUIに返す。
UI側は、ロックして読み込み時点と現状が一致しているなら置換してアンロックそして処理終了。
ロックオブジェクトが自分自身に限られるからデッドロックの可能性はない。
この方法の場合、読み出すだけならロック不要でいつでも読み込めるしね。
俺は、UIに関してはそういう設計にして自分のメソッドはすべてスレッドセーフだ。
長年の実績ある方法だし、このやり方は非常に優れていると思う。
更新失敗とリトライは発生するが、並列度はかなり高くなる。
デッドロックは皆無で、見通しも良い。
- 615 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 12:55:44.66 ID:Un9Q+jtZ.net]
- >>589 に追加
これのよい所は、バージョン管理システムは普通誰でも使わなきゃならないもので
どういう風に機能させるのか誰にでもすぐ分かる。
問題が発生しても初心者に簡単に解決できるという点が良いと思っている。
- 616 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 17:07:47.97 ID:EtPn1ouj.net]
- なんか酷いやり取りだね
マルチスレッドを根本的に理解してないのが何人かいるねw
スレッドセーフに作ることは高コストだから特に理由がない限りそうしないのは
マルチスレッド理解の初歩の初歩だと思うんだけど。
あれだ、UIは別スレッドからのアクセスを検出して例外投げるようになってるわけだけど、
例外が投げられなければ何も問題ないはずだ、っていうVBerな発想なのかねw
- 617 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 17:21:43.84 ID:ncdnXTN/.net]
- .NETは実行コストよりも実装コストを重視する傾向にあるからね
スレッドセーフなformになってもいいと思うわ
- 618 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 17:24:03.63 ID:30c+rZIc.net]
- >>592
君のコードはイベントハンドラが並列に実行されても大丈夫?
利用する側の実装コストも確実に跳ね上がるよ
- 619 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 18:15:58.21 ID:ncdnXTN/.net]
- マルチスレッド動作のformにとは言ってないんだよ・・・
- 620 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 18:57:02.57 ID:99dRkoLd.net]
- >>592
そこでwpfのバインディングですよ
- 621 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 1
]
- [ここ壊れてます]
- 622 名前：9:28:24.32 ID:Un9Q+jtZ.net mailto: >>591
酷いやり方というのはある意味正しい
そもそもformsが腐っている以上綺麗な方法はハナから存在しない。
それでも誰にでもわかり、誰にでも修正可能なやり方っていうのが重要なんだよ。
それができなきゃ、一人で勝手にやっていろって話になる。
チームで作業は不可能だ。 [] - [ここ壊れてます]
- 623 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 19:30:23.84 ID:Un9Q+jtZ.net]
- バインディングとか最悪やな、何処がどうなっているのか把握できる人間が居なくなって
誰にもメンテできなるなる典型w
- 624 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 19:32:40.10 ID:Ei+8urX3.net]
- >>583
> GUIライブラリからアプリケーションをコールバックしたりと、
これってあるか？ピンとこない。
そもそも、UIってロックする必要があるか？
現状、UIスレッドとタスクスレッドは別で、結果的にプログレスバー等の更新にはinvokeを使うしかない。
これがウザイから「直に書き込みさせてくれ」というのが俺の希望。
そもそも、排他的な実装をしなければならない理由がないだろ。
プログレスバーなんて普通は共有しないし、
してたらしてたで「どちらの内容が表示されてもいい」が仕様になるのだから、
レーシングしたところで問題ない。
結果、リクエストがあったらただ更新すればいいだけ、それを表示すればいいだけ、で終わりじゃないか？
ファイルみたいにロックありきの物ではないと思うんだが。
- 625 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 19:35:54.46 ID:g/kXmQSp.net]
- マルチスレッドアクセス可能なGUI採用してるシステムなんてあったっけ
UIスレッドモデルが遺産だというのなら
新しいシステム(Windowsに限らんぞ)ほど「そうなってはいない」はずだが
実際は最近のOS(やはりWindowsに限らない)でもUIスレッドモデルだ
何故だろうなあ
下手の考えなんぞ大抵は
「先人が思いついたけどあえてやらなかった」か「すでに失敗した」か
- 626 名前：デフォルトの名無しさん [2017/03/23(木) 19:36:15.02 ID:Un9Q+jtZ.net]
- Haskellみたいに極度に小さい記述で複雑なシステムが組めるのは確かに凄いんだよ
あれはマジ使える、ただし誰にでも使えるものでは無い。
こういう物は、チーム作業には向かない。
少人数で高度なプログラミングをするのには向いているがね。
で、C#はHaskellみたいなアプリケーションを作るために開発されたものなのかというと、それは違う。
誰でも使えるBasicの延長線上のものだ。
TaskもWPFもHaskellみたいな超絶技巧を目指しているだな、そんなものは要求されていないのに。
- 627 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 19:37:49.41 ID:Ei+8urX3.net]
- >>595
あー、WPFのバインディングはこれを目指していたのか。
なるほど俺の要求だけならこれでいいわ。
- 628 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 19:39:47.03 ID:FkdET+B0.net]
- 不思議だな
新しい技術のおかげでプログラミングはますます簡単になってるのに
まるで難しくなったような意見が出てくる
- 629 名前：デフォルトの名無しさん [2017/03/23(木) 19:40:57.33 ID:Un9Q+jtZ.net]
- 結局ね、マイクロソフトの技術者はコンセプトという物が理解できないバカの集団と化してしまったんだよ。
多分、社内政治とスタンドプレーの果てにこうなったんだろうなと。
だから、マイクロソフトは象牙の塔。
勉強しまくっているが自分のやっている事しか見えていない奴が音頭を取り始めてしまっている。
- 630 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 19:46:09.55 ID:J2eFkRx5.net]
- ほーん、で？いちいち同意求めんなカス
知恵袋で恋愛相談してるクソアマかテメー
- 631 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 19:57:59.50 ID:HovpjxiM.net]
- >>589
> UI側は、ロックして読み込み時点と現状が一致しているなら置換してアンロックそして処理終了。
一致してない時に再計算をする必要があるからその計算が軽い時に有効な方法
ちなみにバージョン管理システムでは他の人が変更してるからやり直せって言ったら使い物にならないのでいわゆるマージ処理を行うのでちょっと違う
- 632 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 20:26:39.42 ID:HovpjxiM.net]
- >>598
GUI 組んだことないのか？
イベントってフレームワークからのアプリケーションの呼び出しだぞ
あとロックするのは GUI のフレームワークじゃなくてア�
- 633 名前：vリケーションの方
マルチスレッド化したフレームワークだとイベントっていつ発生するかわからないのでお前みたいなよくわかってない奴が組むとデッドロックを引き起こしたりしやすいって話 [] - [ここ壊れてます]
- 634 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 20:27:34.06 ID:99dRkoLd.net]
- >>601
但しコレクションに関してはBindingOperations・・・のおまじないが必要だ
- 635 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 20:48:03.89 ID:Ei+8urX3.net]
- >>606
今時GUIしかやらんだろ。
が、まあこっちの認識がずれていたのは分かった。
>アプリケーションからGUIライブラリを呼んだり、
>GUIライブラリからアプリケーションをコールバックしたりと、
>双方向に呼び出すことが多く、
前者が「プログレスバーの更新」で、
後者が「 XXX.click += YYYY;」か。
確かに双方向だ。
で、ロックは必要か？
プログレスバーの更新なんて、ロックする必要ないだろ。
他もそうだと思うが。
- 636 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 20:49:29.54 ID:30c+rZIc.net]
- >>606
具体的な最大の問題は、マルチスレッドアクセスを許容するとUIスレッド上で排他処理をしなきゃいけないことなんだよな
UIスレッドは多種多様なタスクによってタイトに使い回されるので、それをブロックすることは容易にデッドロックを引き起こす
UIスレッド上で別の処理Xが終わるのを待ってたら、XもUIスレッド上で呼び出される処理で
いつまでもXが呼ばれなくなりデッドロック、というのはよくあるパターン
- 637 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 20:55:57.96 ID:30c+rZIc.net]
- >>608
そのプログレスバーの更新一つとっても中でどれだけ複雑なことをやっているかは君にも想像できるだろ?
君がロックしてるつもりがなくてもプログレスバーの更新処理を呼び出せば内部で当然ロックがかかる
- 638 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 21:00:57.40 ID:Ei+8urX3.net]
- >>609
普通に組んだらデッドロックはしなく無いか？例えば、
1. UI <- Task_thread_A で Aが止まる。
2. Task_thread_A <- Task_thread_B で Bが止まる、ここまではありがち。
3. Task_threadB <- UI ：これはねーよ。
UIスレッドがTaskスレッドを見てロックするという使い方は普通しないだろ。
- 639 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 21:14:48.29 ID:Ei+8urX3.net]
- >>610
いや、ロックの必要はないだろ。
正確に言えば、外部からの明示的なロックが必要無いように作れば作れるだろ。
今そうなってないだけで。
要するにプログレスバーを UI, Task_thread_A, Task_thread_B の
どこからも更新出来るようにしたいとして、
全部、 progressBar.value = x; と書かせろ、と言いたいだけで。
内部的に細かくロックして、順に処理するのはCLRが勝手にすればいい。
その結果、それぞれのスレッドが微妙にロックするのも仕方ない。
ただ、循環ロックにならない限り、デッドロックにはならないだろ。
そして普通に書けば、循環ロックにはならないだろ。
- 640 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 21:17:21.47 ID:5A+rvbXC.net]
- 独りで仕方ないと思って存分に射精してろハゲ
- 641 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 21:24:07.98 ID:NnBP2eXC.net]
- >>608
GUIしかやらない？どこの世界の話だよ
- 642 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 21:27:34.82 ID:VjAjr2s9.net]
- >>589
アトミックなデータでない限り、読み出しでロックが不要は誤り。
更新中の中途半端なデータが読みだされたらどうすんの。
- 643 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 21:30:44.46 ID:5A+rvbXC.net]
- 生兵法はケガの元だな
毛がなくて良かったね～
- 644 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 21:32:55.65 ID:HovpjxiM.net]
- >>608
> あとロックするのは GUI のフレームワークじゃなくてアプリケーションの方
の意味を理解してないのかよ...
そりゃ単純にプログレスバーに表示するぐらいなら問題は発生しないよ w
例えば複数の銀行口座の預金額を表示して振り込みを行うアプリケーションを作るとして
他の端末から入/出金があるのです定期的に預金額を更新しようとしたら各口座をロックして値を読み出してロック解除して画面を更新するだろ
でないと額の不整合が起きるからな
このロックして時に振り込みボタンが押されたら当然こっちも振り込み元と振込先の口座をロックしないとダメだろ
でこのロックの順番がテレコになってたら簡単にデッドロックをするって訳
もちろんちゃんとロック順序を考えて組めばいいんだけどでかいシステムをよくわかってないドカタに組ま
- 645 名前：せることを考えたらわざわざそんな危険な構造にする意味がないってこと
前にも書いたけどUIなので超高速で画面のあちこちが更新できても意味ないしな [] - [ここ壊れてます]
- 646 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 21:33:06.10 ID:0wLqn0eU.net]
- >>588
寝ぼけるのはいいかげんにしろ。
- 647 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 21:34:23.52 ID:5A+rvbXC.net]
- 3行以上はキチガイ
- 648 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 22:20:43.54 ID:ncdnXTN/.net]
- >>617
> 定期的に預金額を更新しようとしたら各口座をロックして値を読み出してロック解除して画面を更新するだろ
そういう糞UIでもつくれるけど、まともだったらやらないよ・・・
- 649 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 23:30:21.13 ID:u0oYY3Ci.net]
- >>620
で、お前はどうやるんだい？
- 650 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 23:38:12.29 ID:uQaoHdGv.net]
- 普通は読みだす時はロックなんてしないよw
複数のデータの不整合が問題になる場合は微妙だけど、その場合でも
2回一致するまで読む方が低コスト
- 651 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 23:39:06.22 ID:uQaoHdGv.net]
- っていうか、何でこんなマルチスレッドの初歩みたいな話になってるの？w
- 652 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 23:47:48.47 ID:Ei+8urX3.net]
- てす
- 653 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 23:50:59.28 ID:Ei+8urX3.net]
- >>617
ちげーよ。まあ結論としては、簡単に出来るけどC#はやらなかった、というだけだ。
そして俺はこの選択は間違いだったと見るね。
実装例としては以下。(C#の文法は知らないので真似てみた。適宜脳内修正よろしく）
//ここにコードを書いたのだが、403 Forbidden になるぜorz
mutexを使う場合、mutex確保中に他ロックを取りに行かなければデッドロックはしない。
或いはthread_IDを付けておいて、UIなら直接変更、その他ならinvokeにしてもいい。
いずれにしても、ユーザー側にはinvokeが見えなくなる（隠蔽される）
これの方が良かったと思うよ。いちいち混乱しなかった。
そちらの例は、2人のユーザ間でのデッドロックであって、
俺が今話しているUI/タスクスレッド間の例じゃないじゃん。
なお、解法は、普通に「両方取れなかった場合は一旦全部リリースしてリトライ」でいい。
ただし今時はそれはDB任せで、ユーザ側でのロック管理なんてしない（はず）
- 654 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 23:52:19.70 ID:FkdET+B0.net]
- スレ読み返すと細かいことはどうでもいいけどとにかくInvokeしたくないプロパティでアクセスさせろって暴れてる変な子が居るように読めるんだが
Invokeを適当なプロパティでラップしろで終わる話じゃないのこれ？
- 655 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 23:53:41.78 ID:u0oYY3Ci.net]
- >>622
ケースバイケースだろ
そもそも >>617 は説明のためのサンプルだから不満なら両方書き込みのケースを考えればいいだけ
>>623
マルチスレッドGUIフレームワークに夢見てる奴がいるからでしょ w
- 656 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 23:54:44.80 ID:Ei+8urX3.net]
- >>626
その通りだ。そしてそのコードを貼ろうとしている。
つか、貼らなくても分かるんならもういいね。
- 657 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 23:57:20.64 ID:u0oYY3Ci.net]
- >>625
> 俺が今話しているUI/タスクスレッド間の例じゃないじゃん。
そんなことを言ってるのお前だけ
>>583 をちゃんと読み返せよ
- 658 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 00:00:02.01 ID:Lq7k+m1v.net]
- >>622
そんな力業してないでリーダー/ライターロック使いなよ。
比較のループとかデータ量次第ではCPUパワーの無駄遣いだろ。
- 659 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 00:07:18.67 ID:P/PrHj1p.net]
- 既製品に文句があるなら自分で作ってgithub
これができないプログラマはいつまでも三流のまま
コードを書き使ってもらい持論を証明するんだよ
- 660 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 00:13:35.16 ID:OAgok+ci.net]
- Windows Formsの場合は、単純にFormがActiveXコンテナになり得るから、
アパートメントの制限に対応するために用意された、実装上の都合による物だよ
おそらく、ロックの問題ではなく
リソースリークを根本的に解決する方法がないから用意された手続きなんだよ。
ラップして
- 661 名前：解決できると思うなら、それで良いんじゃないか []
- [ここ壊れてます]
- 662 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 00:14:57.73 ID:gW3AbLz/.net]
- だからUIスレッドが気になるなら、wpfでMVVMやれば解決でしょうに
- 663 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 00:38:36.13 ID:9w5lj4S/.net]
- UWPで非同期メソッドとかTask使ってるけどすごい不毛。
非同期メソッドの完了を基本的にはawaitで待つから
非同期メソッドを複数回実行するような場合だと
全部同期呼び出しにして全部まとめてTask.Runしたい。
- 664 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 00:50:30.06 ID:RtKD05ZR.net]
- >>630
俺は622じゃないけど。
従来型のロック機構だとコストが高すぎる場合もあるんだよ。
俺は詳しくないけど、多分Erlangとかの世界で。
mutex等は共有メモリへの書き込みが生じるから実はかなり重い。
- 665 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 02:13:48.63 ID:5bMFJR3b.net]
- 馬鹿にマルチスレッド。
- 666 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 02:33:18.25 ID:99176uAd.net]
- 結局少しでも重たい処理は全部ワーカーにしなけりゃならないから
UI弄る時だけInvokeした方が見通しすっきりするんだよねw
async/awaitとか使うよりは
ここがUIスレッドですってはっきりわかる。
- 667 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 02:44:50.15 ID:7cONiVN5.net]
- ここはまだWinFormsの時代かｗ
- 668 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 02:50:50.13 ID:99176uAd.net]
- WPF？誰が使うか
そんなもんが必要なモバイルなら普通にJavaScriptにWebアプリで行くわって感じだねw
- 669 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 03:11:50.24 ID:m/Lurhmo.net]
- >>612
progressBar.Value+=1
としたときに
1.読み込み
2.加算して書き込み
の処理が必要とすると、1と2の間に別スレッドが書き換えを行うことで結果が矛盾する
Interlocked命令を使えばそれは防げるけど、MaxValueを超えないかとかの判定が入るので結局ロックが必要
この程度ならまだしも、裏でWin32やCOMを叩いてるコントロールはさらにややこしい
- 670 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 03:44:24.59 ID:5bMFJR3b.net]
- レベル低すぎて引くわ C#、LINQ、WPFが高速とか言ってたおれ最先端君が戻ってきたのか？
- 671 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 06:28:32.59 ID:Cpc8yNoh.net]
- 高速(で書ける)
- 672 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 07:23:36.10 ID:vGZXBTd1.net]
- 高速で壊れるの間違いだろ
馬鹿はphp書いてろ
- 673 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 07:56:00.46 ID:P/PrHj1p.net]
- >>640
壊れても遅くてもいいからとにかくプロパティで書きたいというのが要件
- 674 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 08:24:47.57 ID:gW3AbLz/.net]
- データの保証がないコントロールなど、標準品ではありえないから
頑張って作ってくれとしか言いようがないな
- 675 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 12:55:58.77 ID:99176uAd.net]
- >>645
横だけれど、そもそも問題としてValueをインクリメントする事自体が余り良くない考え方かもね。それは表示と処理が分離できていないから。
カウント処理のカウンターはUIがもっているべきじゃない。
別途カウンターを作って、結果だけをUIに代入すべきだ。
このように設計されているなら、破損無視で書き込んでもうまく動作するだろうと思う。
問題は、それをすべての人に要求するのは難しい、自分の忙しくなったらきちんとせずにインクリメントしてるしなw
という事なんだな。
- 676 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 15:14:34.51 ID:suDsBIm1.net]
- やっとまともなやつ来た
- 677 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 16:13:38.13 ID:m/Lurhmo.net]
- >>646
今もそうなってるじゃん
ProgressBarクラスがカウンターを持ってて、ネイティブのmsctls_progress32にメッセージを送って表示を更新してる
ぜひスレッドセーフに再実装してみてくれ
- 678 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 18:30:43.13 ID:kZHdS/d5.net]
- >>646
> カウント処理のカウンターはUIがもっているべきじゃない。
そんな低レベルな話をしてるのは ID:Ei+8urX3 だけだから、お前らもうでてくるな
- 679 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 19:42:33.91 ID:RtKD05ZR.net]
- >>640
> 結局ロックが必要
いや、要らん。正確には、要らない組み方はある。
アトミックはデータを構造体にして参照を持つことで解決出来る。(一発ライト）
レーシングはインミュータブルとCASで解決出来る。x86ならCMPXCHG命令。
具体的には以下。
1. まず有効な値かどうかを先に判定する。（これは今も先にやっているはず）
2. 書き換える場合、元データのポインタをローカルにまず確保する。
3. 上記旧ポインタから参照して、書き込むデータを
new ProgressBarData() で新しく作る。（インミュータブル）
4. 本体のポインタをCAS命令(LOCK付き）で差し替える。
5. 失敗した場合は3からリトライする。（CAS命令の結果に最新ポインタが入っている）
この方法だとメモリを余分に食うけど、ロックは要らなくなる。
(なおErlangは共有メモリ無しで全て通信という別解決方法だった）
いずれにしても、やりようはあるんだよ。どこにコストを掛けるかという話で。
そもそもGUIなんてレーシングしても問題ないようにも組めるし。
(ProgressBar.value += なんて要らない。 = だけでも組める。>>646に同意)
その上で、invokeなんてユーザーに見せる必要あったのか？というのが疑問。
.NETはVC++でも使うから少しでも速い方がいいという需要もあるのかもしれんが、
C#のノリならここは隠蔽して欲しいところでしょ。GUIなんて極限まで速い意味はないし。
ラップしてもいいし、上記のようにロックフリーにしてもいい。
(もちろんユーザがやってもいいんだが、そういう言語じゃないでしょ）
https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%9A%E3%82%A2%E3%83%BB%E3%82%A2%E3%83%B3%E3%83%89%E3%83%BB%E3%82%B9%E3%83%AF%E3%83%83%E3%83%97
https://ja.wikipedia.org/wiki/Lock-free%E3%81%A8Wait-free%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0
つかいつからお前らこんなに馬鹿になったんだ？ふらっとから混ざったのか？
ロックの設計の仕方を知らないのはお前ら全員じゃねーかよ。
- 680 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 19:51:21.19 ID:9LJ2CaVF.net]
- >>650
なーんかしょうもない話を延々続けて頭悪そうだけど、
特に理由がない限りわざわざスレッドセーフに作らないのはGUIに限らんって何度言えばわかるの？
馬鹿なのかほんと
- 681 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 19:54:06.25 ID:HsxCjAja.net]
- >>650
2と3もロックされなければ既に破棄され別の領域として
再利用された誤った情報を読み出す可能性があるだろ
- 682 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 19:54:24.48 ID:9VMQOfeX.net]
- MSにとっての実装コストの問題でもあるしな
MSが苦労するのはいいとしても、その結果激増したバグに悩まされるのはお前らだぞ
- 683 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 20:07:48.70 ID:RtKD05ZR.net]
- >>651
お前がinvokeをウザイと思わなければそれでいい。
俺はinvokeをウザイと思うからMSが隠蔽しとけ、と思う。
多分後者の方が多いだろ、この件に関しては。
>>652
ついにC#がGC言語だと知らない奴も出てきたか、、、
>>653
MSはこの程度ならきっちり実装出来るよ。
というかMSって比較的まともだと思うぞ。
- 684 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 20:09:50.64 ID:UKoqSEXl.net]
- BeginInvokeはどうするの？
- 685 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 20:15:53.11 ID:RtKD05ZR.net]
- というかここでも単発は池沼なんだな。
いちいち言ってることがアレだし。
- 686 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 20:24:26.17 ID:RtKD05ZR.net]
- つかまあ、百歩譲って他のコントロールならいいよ。
ただ、ProgressBarなんてどう考えてもタスクスレッドから書き換えられるのが仕様だろ。
(むしろUIスレッドから書き換えることがない)
それをいちいちinvokeはねーだろ。
せめてProgressBarだけでも対応しとけよと思うだろ普通。
- 687 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 20:27:59.45 ID:9LJ2CaVF.net]
- >>656
アレなのはお前だよ馬鹿...
しかも重症のな。
何度も言うけど、こんなのはweb上にあるようなマルチスレッドの入門記事レベルの話だ。
そもそもスレッドセーフってどういうことなのかすら理解してないし、自分でそういうコードを書いたこともないだろお前。
しかし、
- 688 名前：こういう馬鹿に限って偉そうなのは何なのかね []
- [ここ壊れてます]
- 689 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 20:32:42.95 ID:RtKD05ZR.net]
- 皆さん、今からスレッドセーフ大先生の講義が始まります。ご静聴下さい。
ではよろしく>>658
- 690 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 20:57:32.53 ID:UKoqSEXl.net]
- ＞せめてProgressBarだけでも対応しとけよと思うだろ普通。
ProgressBarを対応させたら○○も対応させろとか言い出す人が出ると思うでしょ普通
- 691 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 21:56:51.21 ID:vGZXBTd1.net]
- 馬鹿+偉そうときたから例外を握りつぶすニキだな
- 692 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 22:04:34.44 ID:vGZXBTd1.net]
- ああでも今回はさすがにClickOnceは危険ニキを支持だな
＞MSならこの程度はきっちり実装出来る
ここが一番面白かった
- 693 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 22:13:22.45 ID:RtKD05ZR.net]
- つまり、俺が言いたいのは、以下ね。
>>559 > invokeってフォームに限ってどうして必要なのですか？
老害： それがしきたり。
ゆとり池沼連呼リアン>>658： スレッドセーフ！スレッドセーフ！
俺： MSが馬鹿だから。
ゆとりって連呼リアン程度の知能しかないよなマジで。
そもそも俺の>>650は>>589（俺ではない）とほぼ同じ内容だぞ。
お前ら馬鹿が付いて来れてないから書き直しただけでね。
お前らが589を最初から理解していればもっとマシな議論だったろうさ。
- 694 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 22:24:18.31 ID:9LJ2CaVF.net]
- だからスレッドセーフじゃないのはControlのメンバだけじゃないって言ってるのに懲りない奴だな
馬鹿なのはMSじゃなくてお前だっての馬鹿
- 695 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 22:36:30.53 ID:9LJ2CaVF.net]
- Control「だけ」がメンバをUIスレッドからしか呼べないとか訳の分からん錯覚をしているのは、
Controlのメンバが非ユーザーコードからも呼ばれることを理解してないからだろうなたぶん
- 696 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 22:41:45.59 ID:RtKD05ZR.net]
- スレッドセーフ君はやはり連呼リアンであったか、、、
お前がそう思うんなら(ry
- 697 名前：デフォルトの名無しさん mailto:sage [2017/03/24(金) 22:42:26.38 ID:9LJ2CaVF.net]
- 馬鹿な上にネトウヨって人生終わってるな
- 698 名前：デフォルトの名無しさん mailto:sage [2017/03/25(土) 01:12:27.10 ID:66tFvNtY.net]
- >>657
こんなもんで余計なパフォーマンス食われるのも嫌な感じだしね
スレッド無視で叩きこめるならその方がありがたい物ではある。
インクリメント問題くらいならこっちで対処するわって感じですな。
- 699 名前：デフォルトの名無しさん mailto:sage [2017/03/25(土) 01:17:38.46 ID:66tFvNtY.net]
- ああ、そういえば高負荷バックグラウンドスレッドで
progreassBarの操作をasync/awaitでブチかましてスレッドプール爆発させてた新人いたな(笑)
凄い困ってたけど、きっと何が何だか分からなかったんだろうな。
- 700 名前：デフォルトの名無しさん mailto:sage [2017/03/25(土) 01:39:16.42 ID:O6oCv4KM.net]
- >>668
そもそもコードの設計論から言ってもワーカースレッドからUIを操作するなんてありえない。
UIに依存するモデルってどんな糞設計だよ。
モデルにSynchronizationContextとか持たせてUIスレッドに同期したイベントで通知させるのは
設計としてありだけど、直接コントロールをいじるとかありえん。
それも気に入らないならUI側が能動的にタイマーでも使ってモデル側を読めばいいだけ。
- 701 名前：デフォルトの名無しさん mailto:sage [2017/03/25(土) 04:16:02.72 ID:++OH//Pd.net]
- VB上がりにモデルなんて概念ないからｗ
- 702 名前：デフォルトの名無しさん [2017/03/25(土) 09:54:01.33 ID:QDpQza6M.net]
- .NETの質問したいんですがここで大丈夫でしょうか？
とりあえずします。
PictureBoxのPaintイベントでImageプロパティを再設定する処理などをしてるんですが
どうもMessageBoxの挙動がおかしくなってます。
フォームより後ろに表示されてしまって操作不能になってます。
とりあえず通常のメッセージボックスの場合はパラメータを弄って強制的に全面に表示させてますが
困るがSaveFileDialogなどで上書き確認のメッセージボックスが表示された時です。
この場合も後ろに表示されてしまって操作できない
- 703 名前：のでどうしようもないです。
これを回避する方法はどうやればよいんでしょうか？
Paintイベントの中身を消去すれば普通に表示されますが出来ればそのままでメッセージボックスも前面に表示させたいです。 [] - [ここ壊れてます]
- 704 名前：デフォルトの名無しさん mailto:sage [2017/03/25(土) 09:57:11.64 ID:iGx2aDuI.net]
- Paintイベント内の処理がおかしいんだろ
俺たちはエスパーじゃないんだから、まずそれがどんなコードか教えてくれよ
- 705 名前：672 mailto:sage [2017/03/25(土) 09:57:40.89 ID:QDpQza6M.net]
- すいません。自己解決しました。
Paintイベントで毎回PictureBoxのImageプロパティを再設定してるのが原因でした
下記のように条件を入れてやるだけで回避できました。
if(pic.Image != img){
…
}
- 706 名前：デフォルトの名無しさん mailto:sage [2017/03/25(土) 09:59:45.97 ID:swqPfyBg.net]
- だと思った
- 707 名前：デフォルトの名無しさん mailto:sage [2017/03/25(土) 10:45:00.80 ID:omxknQTj.net]
- DataReaderを使って
while(await ReadAsync().ConfigureAwait(false)) {
...
}
って書いてるライブラリがあるんだけど
件数が多くなりそうなループでasync/awaitするとタスク生成とコンテキスト切り替えのオーバーヘッドで逆にパフォーマンス悪くなったりしないもんなの？
- 708 名前：デフォルトの名無しさん mailto:sage [2017/03/25(土) 11:08:32.17 ID:oe75j5bC.net]
- >>676
ReadAsync使う時点でそれらよりデータソース読み取りの方がコスト大と作者が判断しているんじゃないかね
MemoryStreamに対してReadAsyncとか使っているなら知らんけど
- 709 名前：デフォルトの名無しさん mailto:sage [2017/03/25(土) 11:09:13.59 ID:kGpqWpaU.net]
- >>676
そりゃ呼び出しのオーバーヘッドは増えるだろうけど、それが問題になるかどうかは別だ
パフォーマンスという言葉を安易に使うのはやめよう
君はバッチ処理をしてるのかオンライン処理をしてるのかストリーミング処理をしてるのか、
そのライブラリの方はどういう使われ方を想定してるのか、
処理の規模はどれくらいか
パフォーマンスってのは結果的に目的をどれだけうまく達成できたかであり、一面だけを見て判断できるものじゃない
- 710 名前：デフォルトの名無しさん mailto:sage [2017/03/25(土) 11:11:43.78 ID:2T3avjLL.net]
- パフォーマンスって何を指してるんだ
処理速度出すためにasync/await使うわけじゃないのは理解しているよな？
|
 |
