高負荷時のテキストファイル書き込みで例外が発生する

マー帽さんの書き込み (2006-02-01 07:43) より:

開放漏れではなく、高負荷でガベージコレクションの処理が遅れる事によって
開放が遅延しているのではないかという予想です。
Close メソッド後のリソース開放はガベージコレクションが行いますが、
それは Close 後ただちに行われるのではなく、多少なりとも遅延する可能性がありますよね？

連続して処理するのであれば、遅延するかも知れない開放より
確実に開放してから処理を継続する方が良いように思います。

じゃんぬねっとさんの書き込み (2006-02-01 09:03) より:

引用:
マー帽さんの書き込み (2006-02-01 07:43) より: 開放漏れではなく、高負荷でガベージコレクションの処理が遅れる事によって 開放が遅延しているのではないかという予想です。 Close メソッド後のリソース開放はガベージコレクションが行いますが、 それは Close 後ただちに行われるのではなく、多少なりとも遅延する可能性がありますよね？

それは Dispose メソッドでも同じです。

GC.Collect メソッドを毎回呼び出したりしたら余計に高負荷になります。

マー帽さんの書き込み (2006-02-01 12:09) より:

私が勉強した限りでは違ったのですが、今回は当てはまらないのでしょうか？
下記の「Dispose の実装理由」に書かれています。

Close メソッド後のリソース開放はガベージコレクションが行いますが、
それは Close 後ただちに行われるのではなく、多少なりとも遅延する可能性がありますよね？

じゃんぬねっとさんの書き込み (2006-02-01 12:24) より:

もう 1 度書きますが、Close メソッドでも Dispose メソッドでも、
リソースの回収はガベージ コレクションが行います。

マー帽さんの書き込み（2006-02-01 07:43）より：

開放漏れではなく、高負荷でガベージコレクションの処理が遅れる事によって
開放が遅延しているのではないかという予想です。
Close メソッド後のリソース開放はガベージコレクションが行いますが、
それは Close 後ただちに行われるのではなく、多少なりとも遅延する可能性がありますよね？

連続して処理するのであれば、遅延するかも知れない開放より
確実に開放してから処理を継続する方が良いように思います。

このメソッドは IDisposable.Dispose メソッドのパブリック バージョンで、 IDisposable インターフェイスをサポートするために実装されます。

Dispose は、アンマネージド リソースの解放を指示します。
ガーベッジ コレクションは、マネージド リソースのうち、参照されていないものを回収します（全部を回収するわけではない）。

　で、この事例ですが、私は複数のプロセスが、ログ ファイルにアクセスするのではないか、と考えています。その為に Mutex で、ファイルにアクセスするプロセスを１本に絞ろうとしている、と。なので、わざわざ Mutex オブジェクトを作らなくても、FileShare.None で弾けばいいんじゃないか、と。

yaさんの書き込み (2006-02-01 23:21) より:

2.0から方向性がちょい変わってます。