[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends-ml 12613] 2007/2/17 議事録

皆様、おつかれさまでした。昨日の議事録をアップします。
根本

-----------------------------------
Java読書会　2007/2/17 議事録
吉本　大石　小松　小棚木　岩室　村山　遠藤　高橋　鈴木　高橋　根本(記)

P311より
13 明示的なロック
　ポーリングによる入手
　時間制限付き
　インタラプトで入手

ReentrantLockは必ずfinallyで開放をすること、synchronized method より危険

Javaのfinallyつにいて
C++のdestructor はblockを出るときにlocal変数をdestructorが自動で開放する。のでC++は書き忘れはない。
抜けるときに勝手にunlockする。
C#はdisposableがある。C#ではlockはcompilerが勝手にやってくれる。
lock /unlock のネスト交差させる書き方の要求があれば、unlockが自動開放でないことも好意的に解釈できる。
ReentrantLock は lockしたownerが記録されて、自分がオーナであることがわかる。
ReentrantLockは　自分のlockした中身に再度進入できる。
semaphoreにはownerの考えがないので、誰が開放してもよい。

13-1-1 ポーリングによる入手と時間制限付きの入手
　"back off" とは? ←不明な専門用語
  debit() 引き出し
  credit() 入金
accountオブジェクトにtransferメソッドを最初から持たせるべきか?
トランザクションロジックは外出しのほうがいいはず、しかしlockメソッドがpublicなのは不安。 JDK7でのSuper Package = 公開対象パッケージが指定可能、publicの一段下の制限　　表記法は宿題 long nanosToLock = unit.toNanos(timeout) の表記方法は、お約束パターン13-1-2 インタラプトできるロックの入手13-1-3 コードブロックにとらわれないロック   連結リストに対して、"hand-over-hand locking" or "lock couping" ロックを次々手繰り寄せる方法。   可変長操作の時に有効。その連結の両端のみをつかんでいればよい。   DCAS (Double compare-and-swap) のCPUがあれば、lock free な操作が可能だかDCASは存在しない。13-2 実行性能への配慮   hotspotが最適化したコードはdumpして見るしか手段がない。 binary hack しかない。      (postgreSQLはvacuumとanalyzeは、必ずかけよう)13-3 公平性(fairness)   公平性を操作するoptionはないのか?   軽量言語の場合はプロセス間通信のほぁ
Δⓘ當\xCC13-4 synchronizedとReentrantLockの使い分け13-5 リードライトロック  Javaの場合はすべてのobjectが組み込みlockを持っているのでトレースしやすい。  java.lang.Objectがwait() notify(), notifyAll()をfinalで持っている  java.util.concurrent では　await() signal() signalAll() で衝突を避けている。  JConsoleでアクセスするとdeadlockの検知ができる、しかしReentrantLockの検出は難しい。14 カスタムシンクロナイザを構築する14-1 ステート依存を管理する14-1-1   GrumpyBoundedBuffer  (Grumpy=気難しい)  七人の小人から・・・   ちなみに七人の小人は・・・　　　　　　 Doc 　　　　　　Grumpy 　　　　　　Happy 　　　　　　Sleepy 　　　　　　Bashful 　　　　　　Dopey 　　　　　　Sneezy14-1-2 ポーリングと休眠による荒削りなブロッキング14-1-3 条件キューが助けてくれる　　Object.wait() にタイムアウトは設定可能、waitの引数でセットできぁ
襦▷　\xA1timeoutすると、処理が続行するだけ、timeoutの結果は\xBC
茲譴覆ぁ　\xA1notfifyAll()は引数なしなので、呼ばれたからといって自分の条件が成立したとはいえない。14-2 条件キューの使い方14-2-2 早すぎるウェイト終了14-2-3 シグナル消失14-2-4 通知　List14-8の実装は、本当に空のときしか通知しないので、使うのはちょっと怖い。　表記上notify()とnotifyAll()ではnotify()がデフォルトに見えるが間違い、notifyAll()をまず使うべき。14-2-5 ゲートクラス14-2-6 サブクラスの安全性の問題14-2-7 条件キューをカプセル化する14-2-8 入り口と出口のプロトコル14-3 明示的な条件オブジェクト  wait()      - await()  notify()    - signal()  notifyAll() - signalAll()  という対比で Conditionインターフェイスを使用する。　Objectクラスの方のメソッドはpublic finalなので  隠せない、@Deprecated なら使えるのではないか?14-5 AbstactQueuedSynchronizer  java.util.concurrent.Lockに AbstactQueuedSynchronizerがある。14-5-1 簡単なラッチ14-6 java.util.co!
ncurrentのシンクロナイザの中のAQS14-6-1 ReentrantLock15 アトミック変数とノンブロッキング同期化   compare-and-swap はアセンブラレベルでのatomic操作15-1 ロックの不利な点   Adaptive lockを実行する、お利口なJVMとは誰か?次回(p359) 15-2 ハードウェアの並行性サポート　から