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が建てる事。 建てられない場合は他を指定する事。 577 名前：デフォルトの名無しさん mailto:sage [2017/03/22(水) 21:23:40.38 ID:YDOC/IGa.net] 暫く使ってみたけど、やっぱ、ラピッドリリースはよくねぇよな どんどん品質が落ちていく 誰だよこんな糞な手段はやらした馬鹿は Windows10もVisualStudioもボロボロやん 578 名前：デフォルトの名無しさん mailto:sage [2017/03/22(水) 22:28:00.53 ID:MyrW3Mfd.net] >>555 どんどんお前が老いていってるだけ 579 名前：デフォルトの名無しさん mailto:sage [2017/03/22(水) 22:41:57.96 ID:Qh2JSeLT.net] 最近思うんだけどRazor使わずに普通のhtml+JS+REST API(.NET)の方が開発しやすくない？ Razorって本当に便利なのかな？生産性あがる？ 580 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 01:12:53.78 ID:eX8m9MWo.net] 業務アプリで同じような画面を大量生産するには便利A: [1.201975 sec.]B: [2.281051 sec.] 581 名前：デフォルトの名無しさん [2017/03/23(木) 01:47:02.34 ID:FaFIhE+0.net] C#に限らずかもしれないけれど、invokeってフォームに限ってどうして必要なのですか？ invokeを書けばメソッドを呼び出してプロパティにアクセスできるのは分かるのですが invokeがないと何がダメなのか内部的なことを教えていただけますか？ 582 名前：デフォルトの名無しさん [2017/03/23(木) 01:52:24.45 ID:Un9Q+jtZ.net] >>556 心配しなくても若い子はもうWindowsも使わなければVisutalStduio何それ？状態だからw みんなWeb系でスマホばっかりやっている。 もう、ここに残 583 名前：っているのは年寄りだけだよw [] [ここ壊れてます] 584 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 01:56:59.96 ID:Un9Q+jtZ.net] >>559 昔のシングルスレッド時代の遺産を引きずっているんだよ Formは、半ばラッパーライブラリなので。 シングルスレッドの利点はデッドロックの可能性がないこと。 マルチスレッド当たり前になってしまった今だと、逆にデッドロックの元になってしまったりと困った有様だけど。 遺産の量が大きいので、全く別の物を作るのは簡単ではないだろうね。 585 名前：デフォルトの名無しさん [2017/03/23(木) 02:00:44.79 ID:FaFIhE+0.net] >>561 ありがとうございます もっと詳しく知りたいのですがどう言葉で調べればよいのでしょうか？ できればネットで調べれるものがよいのですが、書籍でも平気です 英語のサイトでも平気です なにかあれば教えていただけますか？ 586 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:04:38.43 ID:VjAjr2s9.net] >>559 UI関連は、UIスレッドでのみ動作することを前提に設計することで、パフォーマンスを上げてる。 マルチスレッド対応にすると排他制御等が増えてしまい、パフォーマンスが下がる。 >>561 非同期処理とか書きやすくなったから、最近は割と楽だろ。 Invokeも使う必要ないし。 587 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:05:51.99 ID:Un9Q+jtZ.net] >>562 C言語から、直接Win32APIを叩いてみればわかると思うよ。 WM_XXXXとかを直接使ってGUIを動かしてみれば、古いインターフェイスの感触どんなもんか分かるかと。 年代物なので、古本屋でWin32の本でも探してみるのもいいかも。 今更みる価値あるのかって思うので、お勧めはしないけど。 588 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:07:28.88 ID:Un9Q+jtZ.net] >>563 Task作った奴はバカだと思うwww Invokeの方がまだ誰にでも分かりやすい。 継続なにそれおいしいのwww 関数型言語面白いねって感じだね 589 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:09:33.89 ID:Un9Q+jtZ.net] このマルチコア時代にシングルスレッドで頑張ってパフォーマンス上げるとか 時代錯誤も甚だしいよな・・・ 590 名前：デフォルトの名無しさん [2017/03/23(木) 02:16:32.78 ID:FaFIhE+0.net] >>563,564 新人にinvokeを教える際に困ってしまったので 浅くでも知識として知っておきたかったので助かりました Win32からの流れなのですね、Formだけこんなに違うのはそういうことなのですね。。 時間があるときにもう少し調べてみようと思います ありがとうございました 591 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:21:34.59 ID:VjAjr2s9.net] >>565 async/awaitやIProgress<T>あるから、Taskの継続を直接使う事はあまり無いな。 間接的には使ってるわけだが。 592 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:21:39.46 ID:9gkqdxMB.net] >>566 時代関係ないから スレッドセーフにするとパフォーマンスが犠牲になるのはUIだけじゃない BCLのクラスのインスタンスメソッドも大半はスレッドセーフじゃない 593 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:22:11.13 ID:Un9Q+jtZ.net] Win32は、当時のオブジェクト指向の実現にむけての試行錯誤が見れるのは面白いかもしれない メッセージ飛ばしたり、メール飛ばしたり、色々試行錯誤の末にC++の仮想テーブル方式にたどり着く訳だけれども その前の段階のオブジェクト指向が見れるよw 594 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:23:39.71 ID:Un9Q+jtZ.net] >>569 いつまでも凝り固まってますねwww もうハイハイって感じですわ 595 名前：デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:28:42.19 ID:Ei+8urX3.net] しかしGUIなんて所詮人間速度だし、パフォーマンスって要らないよな？ フォームに関しては最初からマルチスレッド対応でinvokeの必要無しの方が良かった気がするが。 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にメッセージを送って表示を更新してる ぜひスレッドセーフに再実装してみてくれ

---

---

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

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