0

コードを次から変更できますか:

class Sample{
    private Object _lock=new Object();
    public void someMethod(){
        synchronized(_lock){
            doSomething();
        }
    }
}

に：

class Sample{
    private ISchedulingRule _lock=new SomeSchedulingRule();
    public void someMethod(){
        try{
            Job.getManager().beginRule(_lock);
            doSomething();
        }finally{
            Job.getManager().endRule(_lock);
        }
    }
}

私は「実際の Java 並行性」を読んでいますが、明示的なロックを使用したい場合は、メモリの可視性を保証する必要があると言われています。

質問は次のとおりです。

メモリの可視性を保証できる場合、下部のコードを使用して上部のコードを置き換えることができますか (組み込みの同期を eclipse IJobManager.beginRule および IJobManager.endRule に置き換えます)

4

3 に答える 3

1

ここで見つけたソース コードが最新であると仮定すると、内部に大きなブロックがあるbeginRuleメソッド呼び出しを確認できます。implicitJob.beginsynchronized(this)

于 2012-09-13T16:14:09.267 に答える
0

If your only goal is to achieve synchronization then the answer is yes.

That said, there are some (hidden) gotchas that you need to be aware of. Since JobManager is designed to prevent dead-locks to some extent, then there are somewhat strict rules for using and defining nested rules (a limitation that Java synchronized blocks don't have). There is no public API for checking whether a thread is holding a rule/lock or not. Also, beginRule cannot be canceled by calling interrupt on waiting thread. To name a few.

于 2012-09-14T06:54:39.543 に答える
0

次のステートメントを作成する同時実行に関する Web チュートリアルを見つけました。

Lock インターフェースのコントラクトは、同期と同じメモリ バリアの動作を提供することであることが判明しました。

これは、 の「ロック」インターフェースを参照していますjava.util.concurrent。ISchedulingRuleここに表示されているインターフェースに当てはまるかどうかはわかりません。

于 2012-09-13T16:10:40.160 に答える