読書会(Javaスレッドプログラミング)第4回議事録
[ 戻る ]
Java スレッドプログラミング を読む会 第4回
□ 日時 : 2000/2/24 (土) 10:00から17:00まで
□ 場所: 新宿勤労会館 第二洋室
□ 参加者(敬称略): 高橋(徹)、高橋(智)、亀田、布留川、武川、秋元、石黒、岸田
□ 当日のスケジュール
１. 自己紹介
２. 書記の選出(武川)
３. 読書(読み手 高橋(智)さん)
４. ２次会
P123 2.3.3 オブジェクトの限定
限定についてはP114を参照してください。
引渡しポイントとはなにか?
→P.127のCollections.synchronizedList
アグリゲーションの主要な意味を実装している?
→UMLの記法で「◆と◇」で意味が違ったとおもう。
◆の方はたしかに固定格納と同様の意味だったはず。
2.3.3.1 アダプタ
クラスBarePointはdouble型のフィールドなので、同期しない場合は
不正なdoubleの値になる可能性がある。
ホストがSynchedPointクラスで、部品がBarePointクラスになる。
ArrayList()が同期していたとしても、Iteratorをとってきた場合に
問題が発生しなかったか?
→そういう場合が考えられるときには、2.4.4節のコピーオンライトな機構を
作ればよいのではないか?
2.3.4 グループの限定
任意の重い公式の機構の例とはなにか?
→知的所有権や著作権とかの実世界の機構のはなしで、
リソースに関するはなしはないのではない。
"提供"のy#action()の実装は、なんでこんなに面倒なのか?
x.put(ref);
ref = null;
だけじゃだめなのか?
→上記の方法だとリソースが同時にxとyに存在する可能性があるため駄目。
2.3.4.1 リング
実際どんなときにこのような仕組を使うのだろうか?
→複数のクライアントがあるサービスを共有して使用する場合とかが
考えられるが、たしかにあんまり書く場面はないかもしれない。
P.133 PrintService#startUpServicesの predは何の略語?
2.4 クラスの構造とリファクタリング
リファクタリングとはなにか?
→システムの外部インターフェースを変えずに実装を向上させる技術。
メンテナンス性、再利用性を向上させることが目的。
→リファクタリングツールとしてinteliJというものがある。
http://www.intellij.com/products/renamer/
2.4.1 同期処理の削減
ごまかしの処理とはなにか?
→意図しない処理ということではないか。
「古さが受けいれがたいもの」の古さというのはどういう意味?
→ レジスタ上の値が変更されたが、メモリ上の値が更新されて
ないような場合ではないか?
longとdoubleについてはマルチスレッドのアクセスがある場合はvolatileにすべき。
もし危険を求めるならば...という表現は面白い。
アグリゲートってなに?
→限定をつかったクラス群のことではないか。
しかし、もしアグリゲーションや.....の文の意味がよくわからない。
→いまひとつ話についてけませんでした。
2.4.1.3 オープンコール
Pa141 LinkedCell のソースでvalue()がsynchronizedメソッドだが、
sum()で何度もvalue()をよんでいるのは効率悪くないか?
いっそのことsum()をsynchronizedしたほうがよいのではないか?
→nextがfinalであるという前提があるため、synchronized
を行なう場所がvalueを アクセスする部分に限定できるというのが主旨。
これによりロックが連鎖しない。 これに対してsumをsynchronizedすると、
全てのLinkedCell要素をロックしてしないと、sumメソッドが実行できない。
2.4.2 同期処理の分離
2.4.2.1
P144 の図中の矢印の上のhelperの意味は?
→helperというロールもしくは関係があるという意味ではないか。
PassThroughShapeで何がよくなったのか?
→adjustLocation()と adjustDimensions()が同時に実行できるようになった。
ならば、LocationとDimensionを最初から別のクラスにすべきではないか?
Shapeという単位でアクセスしたい。図形なので位置とサイズは別々より、
一つのオブジェクトとして存在したほうが使いやすい。
2.4.2.2 ロックの分割
パススルー版とロック分割版のShapeクラスのどっちが好みか?
→1つのクラスにまとまっているからロック分割版。
→機能がわかれているからパススルー版。
二つのロックが共に必要になった場合はどうする?
→ロック分割版は、二つのロックを使用するように変更する。
→パススルー版
2.4.2.3 フィールドの分離
フィールドを単純にvolatileと宣言するのはなぜ不十分なのか?
→以前の値を返すsetメソッドなどがある場合(P148のソース)は、volatileでは
排他制御ができない。
2.4.2.4 リンクされたデータ構造
LinkedQueueのputとpollの中でそれぞれlastとheadをsynchronizedしているのはなぜ?
→要素数が0か1の場合lastとheadが同じになるところがミソ。
2.4.3 読み込みのみのアダプタ
Java3Dは結構速いらしい。下手にJava2Dを使うくらいだったら、
3Dで書いたほうがよい場合もある。
2.4.4
2.4.4.1 内部的なコピーオンライト
P158のソース中 IndexOutOfBoundsException を NoSuchElementException に変換
しているが、コールスタック表示が途中で切れてしまうのでは?
→この場合は、すぐ前でエラーがおこっているのがわかるが、
例外を変換する場合は、前の例外をフィールドに持ってコールスタック
表示時にどこで例外が発生したかわかるようにすべき。
2.4.4.2 楽天的な更新
ライブロックとはなにか?
→複数のスレッドがある処理を失敗して、再実行するということを
繰り返す場合のこと。
2.4.4.3 原始的なコミット
CompareAndSwap命令とはなにか?
→TestandSet命令と似たようなもの?
指数的なバックオフスキームとはなにか?
→失敗するごとに、再実行するまでの期間を指数的に増やす方法
スピンするって普通に使われる?
→まわすが普通じゃないのか?
moveToがcommitを持たないのはなぜ?
→moveToは以前の値に依存しないため、commitする必要がない。ただし、
synchronizedなメソッドである必要がある。
shiftXは以前の値に依存するのでcommitする必要がある。ただし、
synchronizedなメソッドである必要はない。
2.4.5 オープンコンテナ
内部ロック、外部ロックとは?
→内部のロックは部品のロックで、外部のロックはホストのロック
2.4.5.1 内部規則
「しかし3.3.4節を参照。」ってよく意味がわからない。
部品のロック
2.4.5.2 外部規則
aPrt.getLock()のサンプルコードはないのか?
2.4.5.3 マルチレベルの制約
2.4.6 参考文献
以上です。
その他の話題としては、以下のようなものがありました。
Dynamic Proxy
JDK1.3の新機能
JDKドキュメントのdocs\ja\guide\reflection\proxy.html
AspectJ
アスペクト指向のツール
テスト用に一時的なメソッドを追加するのに使えるみたい。
http://www.ogis-ri.co.jp/otc/hiroba/Report/oopsla/oopsla.html
http://semicom2.u-shizuoka-ken.ac.jp:8080/~dayz/ddr/AspectJ.html
なんかが参考になりそうです。
JUnit
テスト環境。日本語の資料が少ない。以下のページは結構役にたつ。
http://www.alles.or.jp/~torutk/oojava/maneuver/2000/6-3.html
Ant
マルチプラットフォームな環境でのmake環境を構築するには便利。
□次回の予定
3/20 午前10:00 より 新宿勤労会館 第二洋室 の予定です。
□感想
感想としては、今回も非常に勉強になりました。ここの
議事録には書いてないことでも(書けないor書くの忘れた)
ためになる話がいろいろ聞けておもしろかったです。
それにしてもスレッドは奥が深いです。
高橋(徹)さんもいってましたが
「知れば知るほど、プログラングが出来なくなる」
というかんじです。
#でも書くんですけど。
この本とはあまり関係ないかもしれませんが、
JUnit、Ant、AspectJについては、仕事に役立ちそうなので、
次回までに少し勉強しようと思います。
#余裕があればDynamic Proxyも。。。
あと、事前に本を読まれないという人が結構いて、それでも非常に
理解されているようなので、事前に1,2回読んで、さらに本番でも
読んで、それでも結構難しいと思っている自分にとっては、
ちょっとショックでした。でも、多分、前もって一回読まないと
ついていけないので、やっぱり僕は読み続けると思います。
以上、よろしくおねがいします。
------- 追記 -----------------------------------------------------
こんにちは、Java スレッドプログラミングを読む会第 4 回
で書記を担当した武川です。
議事録に一つ重大な抜けがあったので追加させてください。
P.137においてダブルチェックによる処理について記述されている
のですが、そこで秋元さんが、以下の記事について教えてくれました。
http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-toolbox.html
「Warning! Threading in a multiprocessor world」
という題名でマルチプロセッサ環境だとダブルチェックがうまくいかない
理由について記述してあるそうです。
#伝聞調なのでは、読んでいないためです。
ちなみにそこから派生したはなしで、P.138のソースについては、
プリミティブ型だから問題ないんじゃないか?
という話になりました。
あと、JavaWorldには同様な記事がもうひとつあるそうです。
でも、面倒なのでURLはしらべてません。
------------------------------------------------------------------
-------------
武川 努
takekawa@mars.dti.ne.jp
[ 戻る ]