[過去ログ] GCは失敗。メモリは自分で管理せよ! その2©2ch.net (720レス)
前次1-
抽出解除 必死チェッカー(本家) (べ) 自ID レス栞 あぼーん

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
304
(2): デフォルトの名無しさん [sage] 2015/12/20(日) 12:13:23.36 ID:ofrSOHxv(1/7) AAS
>>303
303(2): デフォルトの名無しさん [sage] 2015/12/20(日) 11:55:11.08 ID:HXRBhwTH(1/3) AAS
C#ではSafeHandleだけ作って後は放置
usingも使わないってのがトレンドだけどね
自分で解放とかバカバカしい
面倒はランタイムに見させて開発者はドメイン設計に集中するって目的を見失うな
オブジェクトの開放を他と独立にやれるケースばかりならそう言えるかもしれんが
オブジェクトAとBがリソースCに依存しているケースでA、Bの開放の少なくとも片方をGCに任せる場合、
リソースCの参照カウンタなりをつかった防護策をプログラマーが書かねばならない
しかしそんな嫌ったらしい雑用を増やすぐらいなら
 Cオープン
 A生成
 B生成
 A, B使用
 B開放
 A開放
 Cクローズ
でええやん?

さらにダンプファイルとかからの障害解析において、オブジェクトが生きているべきなのか死んでいるべきなのか決まっていないとか、
アドレスがはっきりしないとか言う状況は地獄
305: デフォルトの名無しさん [sage] 2015/12/20(日) 12:21:54.48 ID:ofrSOHxv(2/7) AAS
つかこの世はうつろうもののであって、物理的ハードウェアでプログラムを実行する限り、
計算モデルは明らかに状態遷移ベース(チューリングマシン)の方に分がある
GCとかチューリングマシンで無理矢理関数型プログラミングを行うためのつなぎの技術、
いわば邪道
どんだけ蛇が出てくるか、GCの方がかえってわからん
308
(5): デフォルトの名無しさん [sage] 2015/12/20(日) 14:03:49.29 ID:ofrSOHxv(3/7) AAS
>>306
306(3): デフォルトの名無しさん [sage] 2015/12/20(日) 13:48:14.94 ID:HXRBhwTH(2/3) AAS
>>304
設計が悪い
使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
知らなきゃ困るような設計にしたのが間違いだね
>>304の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの?
GCがA、B両方開放してくれるまでDは期限不定で待たされるけどそれが>>306的に良い設計なの?

つまり、ハードウェアリソースの有限性を考慮する限り
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
が常に成立はしないという話
311
(1): デフォルトの名無しさん [sage] 2015/12/20(日) 14:36:58.02 ID:ofrSOHxv(4/7) AAS
>>309
309(1): デフォルトの名無しさん [sage] 2015/12/20(日) 14:28:20.48 ID:i39XsMQ2(1/5) AAS
>>308
そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ?
意見を否定するためだけの極端な反例(この場合は例にすらなっていないが)を引き合いに出すのは不毛だよ
>そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ?
極論なもんカヨ;
例: 表示デバイスの数>表示したいスレッドの数
というのはざらにある

で、>>308のオブジェクトDのケースはどう解決すんのさ…
GCが「いつ開放してくれるかわからない」ブツである以上解消しない問題だとおもうんだけど
(A、BにCのための明示的closeメソッドを付けるぐらいならGCに頼らずに順序管理するわ;
312: デフォルトの名無しさん [sage] 2015/12/20(日) 14:42:20.07 ID:ofrSOHxv(5/7) AAS
解決策の一つはActive ObjectパターンでリソースCの管理を1スレッドXにやらせて
Cに対する要求を全部Xのキューにシリアル化して入れさせるというのがあるが、それはそれで
リソースCを使う全てのオブジェクトがスレッドXに依存するから、Xの開放コードが面倒なことになりかねない
かつ、シリアル化はマルチコア時代のせっかくの並列実行性能を殺してしまう

GCに合わせて生きることは、神仙にでもならねば到底かなわぬ…
315
(1): デフォルトの名無しさん [sage] 2015/12/20(日) 14:48:11.36 ID:ofrSOHxv(6/7) AAS
>>314
314(1): デフォルトの名無しさん [sage] 2015/12/20(日) 14:46:27.58 ID:i39XsMQ2(2/5) AAS
>>311
その例じゃ308の状況にならないよ
どんなコード書いてんだよw
>その例じゃ308の状況にならないよ
なんで?ビデオメモリに2スレッドから同時に書いて無事に済むと思ってるの…;
317: デフォルトの名無しさん [sage] 2015/12/20(日) 14:55:30.48 ID:ofrSOHxv(7/7) AAS
ていうか>>316
316(1): デフォルトの名無しさん [sage] 2015/12/20(日) 14:51:52.93 ID:i39XsMQ2(3/5) AAS
だから同時に書く設計が悪いんだって
気合入れて設計を見直してみろ
そんな必要はないってわかるから
の言っていることはますます矛盾で、
>同時に書く設計が悪い
>そんな必要はないってわかる
というのは明白に「書き込みの順序を設計できる」ということを言っていて、
それはその通り(チューリングマシンの計算モデルに合致する)ので別段漏れの立場と対立するものではなく、
かつ気合を入れて設計すれば順序で全て解決する(GCは不要である)という言明でもある
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.138s*