はい
java-ja
February 24, 2011
145 messages
じゅんいち☆かとう
LockFree lf = new LockFree(); // map = new ConcurrentHashMap() // Normal Store
//
lf.add(...); //Set<Entry> current = this.map.get(key); // Normal Load
上記処理は、Normal Store, Normal Loadなどの Can Reorderは禁止されていないので、命令が順序変更される場合がある。
なので、 mapが観測できない場合がある。でも、ほとんど再現しないと思う。
対策はフィールドにfinalを付ける。
public class LockFree {
final ConcurrentMap<String, Set<Entry>> map = new ConcurrentHashMap<String, Set<Entry>>();
そしたら、スレッドから見える。
JSR-133でfinalはNormal扱いだけど、リオーダーを制限している。http://www.javareading.com/bof/cookbook-J20060917.html#finalFields
「言語仕様 17.5 finalフィールドのセマンティックス」
yoshiori
俺なら Entry の String member に null 渡されたら hashcode とか equals とか compareTo とかで ヌルポでちゃうから、 LockFree の add で最初に値のチェック入れるか、hashcode とかのメソッドを nullsafe にするかなぁ
太一
putIfAbsentはatomicなので、その場合、最初のSetは普通にputされて戻り値がnull。二つ目のスレッドでは、既にputされているSetが返ってくるので、internalAddに処理が遷移する。
じゅんいち☆かとう
public void add(String key, String value) {
Entry newentry = new Entry(value);
for (;;) {
Set<Entry> current = this.map.get(key); // Normal Load
if (current == null) {
Set<Entry> newone = new ConcurrentSkipListSet<Entry>();
newone.add(newentry);
Set<Entry> previous = this.map.putIfAbsent(key, newone); // Normal Load
if ((previous == null) || internalAdd(previous, newentry)) {
break;
}
} else {
if (internalAdd(current, newentry)) { // MonitorEnter
break;
}
}
}
}
Tsutomu YANO
んー気になったのはどっちかというと、スレッドの順序に関係なく先勝ちでSetに対して値が入ればよいのであれば、とにかくadd()読んじゃえば先に勝った方の値が入るんじゃないの？というあたり。同期化してるならなおのこと。
太一
繰り返すけど、このLockFreeオブジェクト自体は動機的に生成されるから、コンストラクタの処理が完全に終了するよりも前に、LockFree#addやLockFree#removeが呼出される事は無いのぜ。
太一
LockFree#getで取ったIterable経由でSetが空っぽになるまでremoveすると、LockFree#addが適切に動作しなくなる事に気付いたのでなおした。https://gist.github.com/842027