C#, C♯, C＃相談室 Part92

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が建てる事。 建てられない場合は他を指定する事。 596 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:30:27.90 ID:9gkqdxMB.net] >>571 いるよね、こういう量的な進歩と質的な進歩の区別のつかない� 597 名前：z 馬鹿な奴だ [] [ここ壊れてます] 598 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:31:53.25 ID:VjAjr2s9.net] 何でもマルチセーフにすれば良くなるってもんでも無いのね。 排他制御のコストは大きいから、なるべくそれを無くす設計が重要。 599 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:32:30.61 ID:Un9Q+jtZ.net] >>572 いやいや、それでもあった方がいいよ マルチスレッドできっちり分散できれば、1CPU辺りの負荷が軽くなる すると低クロックで動いて消費電力が小さい。 シングルスレッドだと、同じ負荷でも1CPUに集中するからクロックが上がってしまう。 600 名前：デフォルトの名無しさん [2017/03/23(木) 02:35:01.08 ID:Un9Q+jtZ.net] >>573 質的にはTaskは逆立ちして徒競走しているようなモンだなw 普通立ってに走れよ、頭オカシイんかいってなもんだね。 601 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:36:32.46 ID:9gkqdxMB.net] しかし、マルチコアっていうのは苦し紛れの「苦肉の策」であってポジティブな進歩じゃないって パソヲタレベルでも知ってる常識だと思ったけどプログラマでもそういう認識がない奴がいるんだね。 そういう奴は「人月の神話」って言葉も聞いたことないんだろうな。 生産性は作業者の投入人数に比例しないのはコンピュータも同じだよ馬鹿 602 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:38:13.08 ID:Ei+8urX3.net] >>575 いやお前実は分かってないだろ。 575はinvokeを肯定しているぞ。てかお前どっち派よ？ 603 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:40:35.49 ID:Un9Q+jtZ.net] >>578 async / await 最新わかってる俺スゲーなヤツが死んでほしい派 技術的には、まぁあるもん使うさってなもんだ。 604 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:57:11.32 ID:VjAjr2s9.net] >>576 Taskはスレッドプールを使いやすくしたもの。 スレッドプール自体は昔から使われるテクニックだし、なんでそこまで嫌うのか分からん。 Taskのおかげで非同期処理が非常に楽に扱えるようになったのに。 605 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 03:07:35.11 ID:Un9Q+jtZ.net] >>580 以前作って滅びたATLなんかと同じだね、入門者がすぐに理解して使えない物は糞 WPFも同様の香りがするね 分からないけれどなんとなく使えているって人だらけになって理解していないから、エラー対処ができない。 そうすると、全部特定の人に負担が行く、そんなコードやライブラリは使えない。 これはマイクロソフトの象牙の塔だよ 606 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 04:45:12.92 ID:0wLqn0eU.net] ATLがいつ滅んだんだよw 607 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 07:10:17.81 ID:UmFjwc/F.net] 昔の名残とかじゃなく、単にマルチスレッドでUI部品を扱うのが大変だということだと思うんだが ユーザーインターフェイススレッド - Wikipedia https://ja.wikipedia.org/wiki/%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%82%A4%E3%82%B9%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89 >例えば、Java の AWT では、1996年の最初の時点では、 >単純にスレッド間でデータ共有型のマルチスレッドになっていた。 >しかし、データ共有するには、ロックをかけないといけないが、 ＞親コンポーネントから子コンポーネントを呼んだり、 >コールバックで子から親を呼んだり、 >アプリケーションからGUIライブラリを呼んだり、 >GUIライブラリからアプリケーションをコールバックしたりと、 >双方向に呼び出すことが多く、 >異なるスレッド間で双方向に呼び合うときは、ロックの順番に注意を払う必要がある。 >これはソフトウェアが非常に複雑になる原因となってしまう。 >また、ロック順序のミスが引き起こすデッドロックは常にではなく >たまに発生したりすることの多いバグ（時間的確率要因が関与する偶発性のあるバグ）であり、 >バグ取りが大変になるという問題があった[ 608 名前：3]。 > >そこで、1997年の Java の Swing からは、 >UI の操作は全てメインのUIスレッドであるイベントディスパッチスレッドから >操作しなくてはならない、というルールを設けた。 [] [ここ壊れてます] 609 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 07:23:37.05 ID:i5lX3ZQq.net] それを昔の名残とかラッパー、速度優先って言ってるんでしょ マルチスレッドにしようと思ったらできるんだから 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

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef