Typemock: その過去・現在・未来
Eli Lopian氏率いるTypemock社の過去・現在・未来について、インタビュー形式にて記します。
News
新しいJavaの並行処理機能: Phasers
作者 R.J. Lorimer, 翻訳者 佐野 徹郎 投稿日 2008年7月24日 午前12時9分
先日、JSR 166(リンク)(並行処理ユーティリティ)の仕様リードであるDoug Leaは、JSR-166yに導入されるPhasersという新しい機能について、166yのConcurrency-interest(リンク)メーリングリストに投稿した。
これまで、ForkJoinTasksに限定されていた、forkjoin.TaskBarrierクラスの柔軟なバリア機能は、あらゆる種類のタスクに適用される、(j.u.c.forkjoinではなく、j.u.cの対象となる)Phaserクラスとして作り直されます。
「Phaser」のコンセプトと名称は、ライス大学のチームによる、このホワイトペーパーの中で(PDF・英語)作られた。この名称は、フェーズの順序付け(Phase ordering)とデッドロックの回避(Deadlock avoidance)という特性の構築に由来する。このホワイトペーパーでは、Phaserのいくつかの詳細について説明している。Phasersと既存のJavaの機能を比較するときに、(Java 5で導入された)CyclicBarrierクラス(リンク)と同様の機能をサポートすると説明されることがあるが、本質的にPhasersはより柔軟だ。
java.util.concurrent.CyclicBarrierクラスは、スレッドの集合に対する同期化の、定期的なバリアをサポートします。しかし、CyclicBarrierはPhasersと異なり、スレッドの動的な追加や削除をサポートせず、一方向の同期化や分割フェーズの操作もサポートしません。
さらなるバリアの実装を検討する、主な動機の一つは、バリアの同期化コンセプトの柔軟性を向上させるだけでなく、パフォーマンスとスケーラビリティも向上させることだ。
3つの異なるSMPプラットフォームでの、ポータブルなPhasersの実装から得られたパフォーマンス結果は、それらが一般的かつ安全な特性による、生産性のメリットに加えて、既存のバリアの実装よりも、優れたパフォーマンスを提供できることを証明しました。
Doug Leaが述べたように、JSR-166yのためのPhaserの実装は、既存のfork/joinフレームワークの実装をもとに、作り直されている。fork/joinフレームワークについては、これまでにもInfoQで繰り返し取り上げたように(参考記事1・英語) (参考記事2)、来たるべきJSR-166yの中心的な機能の一つで、フレームワークの目的と用法を説明する、Doug Leaのホワイトペーパーの主題でもある (PDF・英語) 。上記のTaskBarrierクラスは、さまざまなタスク間の境界を管理し、それらの結果をマージするために、つまり、タスクをジョインするために、fork/joinフレームワークによって利用される。
JSR-166yにおけるPhaserクラスの、ドラフトJavadocも(リンク)見ることができる。Leaは、Concurrency-interestメーリングリストへのメールで、これはまだドラフトであると明言している。
コメントや提案は、いつでも大歓迎です。このAPIは、さらなる利用を検討するため、そしてまた、できれば、もっと良いメソッド名にするため、少し変更するかもしれません。
現在のところJSR-166yは、Java 7の一部として含まれることが、予定されている。
原文はこちらです：http://www.infoq.com/news/2008/07/phasers
No comments
返信