真夜中のconst 性とマルチスレッド

普通のC++使い、銀天すばる @SubaruG

yet another constant qualifier.

Akso de la Malbono @Cryolite

value-based なプログラミング言語で const-ness 云々いうためには，まず one-phase construction を何らかの形で確立しておかないと二進も三進もいかない希ガス．

やまさ @yamasa

@SubaruG 物理的なconst性というのは、コンストラクタ終了後はbitレベルの不変性が保たれる、という意味でしょうか。でも、「bitレベルの不変性」というのも、マルチスレッド環境ではメモリバリアがないと保証できないんですよね。

普通のC++使い、銀天すばる @SubaruG

@yamasa そこまで細かいことは言ってませんよ。要するに、今の const 性の場合は、マルチスレッドでの読み書きの安全性とは対応してないじゃないですか、 mutable があるせいで。それをどうにかして欲しい、と。ロックフリーとかはどちらにせよユーザが頑張らないと無理ですが

普通のC++使い、銀天すばる @SubaruG

「一箇所からの書き込み」あるいは「複数ヶ所からの読み取り」のどちらかのみが行われる限り安全に動作する、って何だっけ。

普通のC++使い、銀天すばる @SubaruG

これか。SGI STL のスレッド安全性。 http://www.sgi.com/tech/stl/thread_safety.html http://hamigaki.sourceforge.jp/doc/html/design-policy.html

イスラエルエリカちゃん @syuu1228

SGIと聞いて！RT @SubaruG: これか。SGI STL のスレッド安全性。 http://bit.ly/a62aCh http://bit.ly/aMlUOK

普通のC++使い、銀天すばる @SubaruG

このレベルでのスレッド安全性があれば十分なんだけど、それすら現行の const では mutable のせいで自動化できない。でも論理的 const 性は非常に大事だから、じゃあ別の const 性、というか readonly 性をもたせられたら嬉しいよね、的な。

やまさ @yamasa

@SubaruG つまり、mutableとかconst_castとかでこっそり内部状態を変化させられることのない、強い意味のconstが欲しいということですね。マルチスレッドは関係なしに。

普通のC++使い、銀天すばる @SubaruG

@yamasa です。 mutable は無いと困るので、余計に。

@iwata_m

スレッドの概念のない C++ に持ち込もうとしたのが、そもそもの誤りだったのよ。。 QT @syuu1228: SGIと聞いて！RT @SubaruG: これか。SGI STL のスレッド安全性。 http://bit.ly/a62aCh http://bit.ly/aMlUOK

やまさ @yamasa

@SubaruG でも、そのような「強い意味のconst」があっても、マルチスレッドでは別途メモリバリアやロックが必要なので、あまり状況は変わらないように思えます。

普通のC++使い、銀天すばる @SubaruG

ちなみに僕のライブラリ設計方針は、 mutable を使う場合はポリシークラスとしてマルチスレッド対応を行なうようにする、それ以外は物理的 const 性と論理的 const 性は一致させる、という方針。

普通のC++使い、銀天すばる @SubaruG

@yamasa ロックをライブラリ側で厳密に書けるメリットは大きいと思うんですよね。 const T に対するロックは複数から読み取れて、的な。

Akso de la Malbono @Cryolite

@SubaruG 目的は十分に理解するんですが，これを達成するには @yamasa さんが指摘されている (と思われる) 状況 (メモリバリアを必要とし，ゼロオーバーヘッド原則と齟齬を起こす文脈) はやはりあるんじゃないでしょうか．やや限定された文脈でのこととは思いますが．

普通のC++使い、銀天すばる @SubaruG

そもそも const をマルチスレッドに使おうなんて考え方がおかしいのかも。その都度手で対応すればいいじゃん？ どうせマルチスレッド対応はデザインの根幹部分なんだし。

Akso de la Malbono @Cryolite

@SubaruG あと，これを目標とする以上， one-phase construction をどのようにして達成するかを並行して議論することが絶対に必要なんじゃないでしょうか．個人的には const-ness 云々を脇に置いておいてこちらを先に深く議論しても良いくらいに思います

普通のC++使い、銀天すばる @SubaruG

すべてのクラスはマルチスレッド対応をポリシーとして持たせるべきである、的なかんじにしちゃえばいいんだよもう。

やまさ @yamasa

. @Cryolite @SubaruG 欲しいとおっしゃっている「強いconst性」というのは、Javaのfinalフィールドに非常に近いと思うんですよ。で、そのJavaでの実現方法がこちらになります。 http://j.mp/9AQKbn

普通のC++使い、銀天すばる @SubaruG

@yamasa スマポとかが絡むと面倒ですからねー。自動じゃなくて表明として使うより無いですな。

Akso de la Malbono @Cryolite

@yamasa 一応自分も Java の final field を想定解として念頭に置いていたんですが，これに関しては完全にど素人なので，こういう資料を refer してもらえて凄いありがたいです．

普通のC++使い、銀天すばる @SubaruG

const メソッドと同様に、「このメソッドでは内部状態を（物理的に）一切書き換えない」と宣言して、仮に書き換えてしまった場合は未定義動作、的な感じにするしかないですにゃー。

普通のC++使い、銀天すばる @SubaruG

ある程度は推移的に判断出来ますが、どうしてもスマポとかが絡むと無理がある。

普通のC++使い、銀天すばる @SubaruG

what ではなく how である以上、完璧に機械的に決めて欲しいけど、流石にゼロオーバーヘッドでそれをやるのは無理ゲー。

普通のC++使い、銀天すばる @SubaruG

や、メタプログラミングを組み合わせれば出来ないことも無いですが