- PR -

「InvokeRequired=True」と「デバッグなしで開始」と「デバッグ開始」

投稿者投稿内容
セラフ
ベテラン
会議室デビュー日: 2005/12/01
投稿数: 95
お住まい・勤務地: 東北の顔の形といえば
投稿日時: 2008-12-12 16:11
スレッドセーフってマルチスレッドで動かしても大丈夫だよっていう「保証書」見たいなものだから、保証外のことをするときは「個人の責任」でってことでしょうね

引用:

また、コントロールに対してスレッドセーフでない操作をすることによって
結局、何がどうなる可能性が考えられるのでしょうか?



なにが起こるかわからないから、スレッドセーフではないということだと思います。

渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2008-12-12 17:00
引用:

バグが発見されやすいようにデバッグ時は例外になるように動作が変更されましたが、デバッガにアタッチしてない状態では、過去との互換性のために例外にはしないようになってたはずです。



そういえばそうでした (^^;
すっかり遠い記憶の彼方でした。

引用:

だから他の理由があるのではないかと考え、
見識のある方の意見を伺いたかったのです。



.NET 2.x ランタイムは、.NET 1.x のアプリケーションの実行をサポートしています。

そのため、.NET 1.x 時代に作られた「スレッド跨ぎのメンバアクセスをしているけど、動いちゃってたアプリ」を引き続き動作させるために、単独実行時には例外を throw しないことにしたんでしょう。

.NET 1.x 時代から、スレッド跨ぎのメンバアクセスは「ダメ」とされてましたが、実際に問題を生じるかどうかはそのメンバの実装に大きく左右されます。

.NET 1.x 時代のコントロールはメンバアクセスがスレッド跨ぎであるかどうかのチェックを(たぶん)まるでやっていなかったので、.NET 2.x 登場時には既に、「ダメなことを知らない人が作ったダメなアプリ」が蔓延してしまっていたのです。
からあげ
会議室デビュー日: 2007/12/13
投稿数: 19
投稿日時: 2008-12-15 10:31
コメントいただいた方々ありがとうございます。

マルチスレッドアクセスにより、発生する可能性のある「なにか」を防ぐために、
.NET Framework 2.0以降では、仕様を変更したのだけれども、
その変更により、.NET Framework 2.0以前に作られた、
数多あるお作法を無視したアプリケーションが動かなくなってしまうしまうことは、
開発者、利用者や社会に対する影響が大きいと考え、その救済として、
デバッグ実行の時のみ、エラーになるようにした。

つまり、この現象は、問題を改修したいのだけれども、
互換性も保証しなければいけないというジレンマに対する、
MSの出した回答ということと勝手に解釈いたしました。

大変勉強になりました。ありがとうございます。

スキルアップ/キャリアアップ(JOB@IT)