限定についてはP114を参照してください。引渡しポイントとはなにか?→P.127のCollections.synchronizedListアグリゲーションの主要な意味を実装している?→UMLの記法で「◆と◇」で意味が違ったとおもう。◆の方はたしかに固定格納と同様の意味だったはず。アダプタクラスBarePointはdouble型のフィールドなので、同期しない場合は不正なdoubleの値になる可能性がある。ホストがSynchedPointクラスで、部品がBarePointクラスになる。任意の重い公式の機構の例とはなにか?→知的所有権や著作権とかの実世界の機構のはなしで、リソースに関するはなしはないのではない。null;だけじゃだめなのか?→上記の方法だとリソースが同時にxとyに存在する可能性があるため駄目。リング実際どんなときにこのような仕組を使うのだろうか?→複数のクライアントがあるサービスを共有して使用する場合とかが考えられるが、たしかにあんまり書く場面はないかもしれない。クラスの構造とリファクタリングリファクタリングとはなにか?→システムの外部インターフェースを変えずに実装を向上させる技術。メンテナンス性、再利用性を向上させることが目的。→リファクタリングツールとしてinteliJというものがある。同期処理の削減ごまかしの処理とはなにか?→意図しない処理ということではないか。レジスタ上の値が変更されたが、メモリ上の値が更新されてないような場合ではないか?longとdoubleについてはマルチスレッドのアクセスがある場合はvolatileにすべき。危険を求めるならば...という表現は面白い。アグリゲートってなに?→限定をつかったクラス群のことではないか。アグリゲーションや.....の文の意味がよくわからない。→いまひとつ話についてけませんでした。アクセスする部分に限定できるというのが主旨。これによりロックが連鎖しない。全てのLinkedCell要素をロックしてしないと、sumメソッドが実行できない。図中の矢印の上のhelperの意味は?→helperというロールもしくは関係があるという意味ではないか。adjustDimensions()が同時に実行できるようになった。LocationとDimensionを最初から別のクラスにすべきではないか?Shapeという単位でアクセスしたい。一つのオブジェクトとして存在したほうが使いやすい。ロックの分割パススルー版とロック分割版のShapeクラスのどっちが好みか?→1つのクラスにまとまっているからロック分割版。→機能がわかれているからパススルー版。二つのロックが共に必要になった場合はどうする?→ロック分割版は、二つのロックを使用するように変更する。フィールドの分離フィールドを単純にvolatileと宣言するのはなぜ不十分なのか?→以前の値を返すsetメソッドなどがある場合(P148のソース)は、volatileでは排他制御ができない。リンクされたデータ構造LinkedQueueのputとpollの中でそれぞれlastとheadをsynchronizedしているのはなぜ?→要素数が0か1の場合lastとheadが同じになるところがミソ。読み込みのみのアダプタJava3Dは結構速いらしい。下手にJava2Dを使うくらいだったら、3Dで書いたほうがよい場合もある。例外を変換する場合は、前の例外をフィールドに持ってコールスタック表示時にどこで例外が発生したかわかるようにすべき。楽天的な更新ライブロックとはなにか?→複数のスレッドがある処理を失敗して、再実行するということを繰り返す場合のこと。原始的なコミットCompareAndSwap命令とはなにか?→TestandSet命令と似たようなもの?指数的なバックオフスキームとはなにか?→失敗するごとに、再実行するまでの期間を指数的に増やす方法スピンするって普通に使われる?→まわすが普通じゃないのか?moveToがcommitを持たないのはなぜ?→moveToは以前の値に依存しないため、commitする必要がない。synchronizedなメソッドである必要がある。shiftXは以前の値に依存するのでcommitする必要がある。synchronizedなメソッドである必要はない。「しかし3.3.4節を参照。」ってよく意味がわからない。その他の話題としては、以下のようなものがありました。ProxyJDK1.3の新機能JDKドキュメントのdocs\ja\guide\reflection\proxy.htmlAspectJアスペクト指向のツールテスト用に一時的なメソッドを追加するのに使えるみたい。http://www.ogis-ri.co.jp/otc/hiroba/Report/oopsla/oopsla.htmlhttp://semicom2.u-shizuoka-ken.ac.jp:8080/~dayz/ddr/AspectJ.htmlなんかが参考になりそうです。JUnitテスト環境。日本語の資料が少ない。以下のページは結構役にたつ。http://www.alles.or.jp/~torutk/oojava/maneuver/2000/6-3.htmlAntマルチプラットフォームな環境でのmake環境を構築するには便利。感想としては、今回も非常に勉強になりました。ここの議事録には書いてないことでも(書けないor書くの忘れた)ためになる話がいろいろ聞けておもしろかったです。それにしてもスレッドは奥が深いです。高橋(徹)さんもいってましたが「知れば知るほど、プログラングが出来なくなる」というかんじです。#でも書くんですけど。次回までに少し勉強しようと思います。あと、事前に本を読まれないという人が結構いて、それでも非常に理解されているようなので、事前に1,2回読んで、さらに本番でも読んで、それでも結構難しいと思っている自分にとっては、ちょっとショックでした。前もって一回読まないとついていけないので、やっぱり僕は読み続けると思います。以上、よろしくおねがいします。回で書記を担当した武川です。議事録に一つ重大な抜けがあったので追加させてください。P.137においてダブルチェックによる処理について記述されているのですが、そこで秋元さんが、以下の記事について教えてくれました。world」という題名でマルチプロセッサ環境だとダブルチェックがうまくいかない理由について記述してあるそうです。#伝聞調なのでは、読んでいないためです。ちなみにそこから派生したはなしで、P.138のソースについては、プリミティブ型だから問題ないんじゃないか?という話になりました。あと、JavaWorldには同様な記事がもうひとつあるそうです。面倒なのでURLはしらべてません。