[jfriends-ml 12434] Re: SharedCounter の実験 (1) - 再送

[murayama <locutus@xxxxxxxxxxxxxxxx>]

村山です．

> > みたいな最適化が許されるわけですよね．
> ループ内のisInterrupted()メソッド呼び出しがループ外に移動する可能性は
> 考えていませんでした。これは単なる実行順序の変更に入るのでしょうか？
「実行順序の変更＋共通部分の括りだし」と思います．
後者をするために前者が必要になっているんです．

> ビジーループでぶん回している中で毎回falseが返却されるので、HotSpotが
> 最適化の一環で常時falseが返ってくると判断してループ外に出してしまった
> ということなら考えられるのですが。

「毎回falseが返却されたから」
ではなくて
「毎回falseが返却されることが保証されたから」
ですよね．そうでないものを勝手に変更するとバグになります．

もちろん，その候補に選んだ理由は「毎回falseが返却されたから」からかも
しれません．

変更可能か否かは，isInterruptedメソッドの(バイトコードレベルで見える)実
装に依存するわけですよね．何度呼び出しても同じ値を返すことが保証される
関数は，ループの内部で何度も呼び出すよりは外で一回だけ呼び出した方が効率
がよくなります．

isInterrupted()が引数を取らない以上はその内部状態だけで戻り値を決めてお
り，内部状態が変更されない限りは，その結果が変わらないのは「ほぼ」自明です．
同じ関数でもマルチスレッドの場合は，ほとんどすべて「変更される可能性有り」に
なってしまい，そのままでは一切の最適化が不可能になります．

それでは困るので「volatile変数やsynchronizedメソッド／文がない場合は
今まで通りに最適化して良い．」として，ある程度条件を緩和しているわけです．


> ちなみに、ThreadクラスのisInterrupted()はnativeメソッドとなっています。

同期が必要な場合はmonitorenter/monitorexitに相当する処理を行う関数を呼び
出すようになっているだけで，nativeメソッドでも扱いはほとんど一緒だと思い
ます．


-- 
murayama <locutus@xxxxxxxxxxxxxxxx>