読書会(JAVA CONCURRENCY IN PRACTICE)第3回議事録

[ 戻る ]

2006/09/09
「JAVA CONCURRENCY IN PRACTICE」第 3 回議事録
時間：10:00 - 17:00
場所：高津市民館　第６会議室

参加者 (敬称略)
高橋（智）、中島、岡沢、根本、村山、岩永、吉本、高橋（徹）、遠藤、岩室、門脇、

早川、小川、山岸、小松

訳者 (敬称略)
遠藤(4.3)、門脇(4.4)、早川(4.5)、岡澤(5.1)，吉本(5.2)，吉本(5.2)，村山(5.3)
書記
小松

☆4.3 Delegating thread safety よりスタート

◆4.3 Delegating thread safety

○リスト 4.8.は unchanging は保証されても snapshot であることは保証されないのでは？
　⇒ConcurrentHashMap の仕様では weakly consistent となっている
　　イテレータ生成後の変更は、反映されるかもしれないし、反映されないかもしれない
　　⇒developerWorks の記事でも注意されている
　　　http://www-06.ibm.com/jp/developerworks/java/040402/j_j-jtp08223.html
　　⇒errata としてあげてみよう　mailto:brian@quiotix.com?subject=JCiP%20Errata

○リスト 4.11.にある private なコピーコンストラクタは private でないとだめ？
　⇒だめという訳ではない
　　ユーザーが使わないだろう、あるいはユーザーに使わせたくないという配慮では

○4.3.5 の文脈では、コンカレントアクセスが安全＋不変式が破られない＝スレッド安全と
　みなしているようだ
　⇒コンカレントアクセスの問題と不変式を破ることの問題は別問題では？

○何でもスレッドにするのはよくない　マルチプロセスの方が安全
　あるスレッドの障害が他にも影響を与えてしまう
　⇒アイソレーションの導入が検討されているが、JavaME での導入が先か？
　　⇒ME ではアプリケーションの障害で VM ごと死んでしまうので優先度が高いのでは


◆4.4 Adding functionality to existig thread-safe classes

○Vector の同期ポリシーは仕様により固定されているとあるが、本当？
　⇒javadoc には synchronized であることは明記されていない
　　⇒仕様とは何を指しているのか？
　　　⇒周知の事実ということ？ソースコードが仕様ということ？

○委譲を用いて既存クラスに atomic な処理を追加する場合、DynamicProxy を使うと楽


◆4.5 Documenting synchronization policies

○Servlet や JDBC のスレッド安全について十分に文書化されていないとあるが、そもそも
　インタフェースしか規定してないので仕方ないのではないか？
　⇒HttpSession のスレッド安全が保証されないことは spec に記載されている
　　Java Servlet Specification Version 2.4
　　SRV.7.7 Important Session Semantics　SRV.7.7.1 Threading Issues
　　==============================================================================
　　Multiple servlets executing request threads may have active access to a
　　single session object at the same time. The Developer has the
responsibility
　　for synchronizing access to session resources as appropriate.
　　==============================================================================
　　⇒Sessionへの同時アクセスはありえるか？
　　　⇒複数からの同時サブミットや重い処理を連続して呼び出した場合など

○@GuardedBy はこの書籍独自のようだが、将来的に名前の衝突が発生することはないか？
　⇒アノテーションを独自パッケージに定義すれば衝突はない
　　⇒java.lang のクラスと同名の別クラスを import した場合、どちらが使われるか？
　　　（宿題）


◆5.1 Synchronized collections

○starvation とは？livelock のこと？
　⇒starvation は、スレッドが必要とするリソースを獲得できない状態（p218 参照）

　　livelock は動いているが毎回失敗して処理が進まない状態


◆5.2 Concurrent collections

○retrieval は何と訳すか？
　⇒この場合（Queue の操作）は「取得」が妥当

○size や isEmpty が並行環境で役に立たないのはなぜか？
　⇒頻繁に変動するから見ても仕方がないということか？
　　⇒技術的な不可能ということか？パフォーマンスとのトレードオフということか？


○backing array は専門用語か？単に裏で持っている配列という意味か？
　⇒backing store という用語はあるが


◆5.3 Blocking queues and the producer-consumer pattern

○... put and take methods as well as the timed equivalents offer and poll.
　はどう訳すか？
　⇒put/take と時限つきで同等のものが offer/poll と読んでおく

○producer-consumer パターンとは？
　⇒生産者-消費者問題と言わんとすることは同じ

○ArrayBlockingQueue と LinkedBlockingQueue の両方があるのはなぜ？
　FIFO に向くのは LinkedList の方では？
　⇒ArrayBlockingQueue と LinkedBlockingQueue の違いは何か？またその使い分けは？
　　（宿題）

○Dequeとは？
　⇒先頭、末尾の双方に対して要素の挿入・削除が可能なキュー
　⇒生産者と消費者が 1 対 1 でキューを持ち、消費者は基本は自分のキューの
head
　　から作業を取り出すが、他人のキューのtailからも作業を取り出す、というような

　　パターン（work stealing）を実現できる

以上

次回は 5.4 Blocking and interruptible methods から
会場は武蔵小杉なので注意！

[ 戻る ]